Template Loaders and Acquisition Mechanism
|
|
Darko Radosevic
|
------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ FreeMarker-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/freemarker-user |
|||||||||||||||||
Daniel Dekany
|
Thursday, October 8, 2009, 3:25:15 PM, Darko Radosevic wrote:
> Hi, > > we have templates placed in folder hierarchy (default/client/site) > and we're using default FileTemplateLoader and acquisition mechanism > to load templates. But now we want to introduce a brand new type of > templates - templates for mobile site. The mobile templates should > follow this same default/client/site hierarchy but they should take > precedence over regular templates when the request is coming from a > mobile device. We could diferrentiate mobile templates by placing in > separate folder or by "m_" name prefix, we haven't decided yet. So, > loading order on a mobile site should be: > > 1. mobile site template 2.mobile client 3 mobile default 4.standard > site 5 standard client 6.standard default > > This looks tricky to solve, I've first tried to utilize > MultiTemplateLoader and some custom TemplateLoaders, but I would get only this loading order: > > 1. mobile site 2.standard site 3.mobile client 4. standard client > 5. mobile default 6.standard default. > > The only working solution I've found so far is to use two > Configurations, Don't do that, it's not how Configurations meant to be used. Templates returned by one of the Configuration-s will search their dependences using that Configuration. This also means that you will end up some templates cached twice... and who knows what else I didn't realized right now. > each having different base folder. In case 'mobile' > Configuration throws FileNotFoundException, try to use 'standard' > Configuration. The problem with this solution is that we'll need > copy all templates from the 'standard' folder to the 'mobile' folder and then maintain duplicates. > > The only other possible solution I see is to rewrite TemplateCache > to maybe somehow move acquisition mechanism inside template loader, > but this looks way too low-level... You couldn't even do that there in a way so it will work correctly. > Do you know of any cases where TemplateCache is overwritten with > some diferrent implementation, or do you know of some Freemarker > features that could be useful for me? Maybe you can do the trick with the localization feature... like if being mobile optimized would be a locale variation (you know, the optional 3rd part of the locale string). Localization quite much does what you need, in that it first tries to find the most locale-specific template variation with acquisition, and only when that fails tries it to find a less-specific one. Now if it doesn't work out well with localization, you can still submit a patch. But then let's see what should be achieved... you want to specify the target *media* here. It's very much like localization right now, so it should look similarly: [hidden email], [hidden email], [hidden email], etc. It's @ because that's also what CSS uses for media selection, and it's also suggestive: the page "at a mobile", "at a printer". I think the media should have higher priority than locale, and that's also what you wanted here. If a different need arises, we can still add a media_priority setting. Yeah, and target_media itself is a new setting. Pretty much like locale. Objections? Of course, you may ask for some guidance if you want to do the patch. > Thanks, > Darko -- Best regards, Daniel Dekany ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ FreeMarker-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/freemarker-user |
||||||||||||||||
|
Darko Radosevic
|
------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ FreeMarker-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/freemarker-user |
|||||||||||||||||
|
Daniel Dekany
|
Wednesday, October 14, 2009, 6:44:06 PM, Darko Radosevic wrote:
> Hi, > > thanks for the helpful response. > > I found some workarounds using the optional 3rd part of the locale > string, but they have some limitations (must supply the mobile > templates for each possible locale, or choose one locale and > therefore make localization unusable). > > Now, about a possible patch. I'm interested in submitting the > patch, but I have some questions. I know whether I need 'mobile' or > 'standard' template at the time when I'm calling > Configuration.getTemplate() method. Will this new 'target media' > setting be an additional parameter in the getTemplate() method, or > it will be new setting in Configuration? Or the setting in > Configuration will be used to enable/disable this new target media > lookup? The way these kind of things work is that (almost) all settings defined on three levels, see: http://freemarker.org/docs/pgui_config_settings.html So, the new target_media setting needs to be added on all 3 levels of FreeMarker. > I guess we need to create an additional method similar to > > private Object findTemplateSource(String name, Locale locale) > > in TemplateCache, or modify this method. Yes, just add a new parameter, String targetMedium, etc. Also TemplateCache.getTemplate will need an overloaded version (because the original is public, it can't be changed), and Configuration.getTemplate too... these are trivial to do too. The template language may will need a new special-variable, .media, akin of .locale, so it's again mostly just copy-paste. What else? I think technically that's it. I will add the relevant parts to the documentation. > I'm not familiar with the Freemarker development process, so I'd > like to know what are the chances for this patch being > accepted/rejected as a part of official Freemarker release? > Do you know some approximate timeframe for this? I'm asking because > this will have an impact on the project I'm working on. Inherently we are not bureaucratic and quite flexible and fast and whatever, but let's see what are the extra hops: - Nowadays you can't contribute without signing a CLA. That's a paper I send to you in e-mail (now), you sign it by hand, and post it to us in snail mail. Yeah, it has to reach a Hungarian address. Sorry about all that, but since big corps started to use FM... you know. After we received the CLA, you get write access to the SVN repo, fire up Eclipse (if you like), and just work and commit... we automatically receive e-mail reports about the changes, so generally you are not expected to ask before committing, as far as you are working on the feature we know about. - Changes should be forward-ported to the 2.4 branch... Easy, but still some boring extra work. - I didn't yet received any responses from the other two "heads", regarding if they agree that this feature has place in FreeMarker. If they don't respond soon, well... I think I will just assume it's accepted. - You don't have to wait for 2.3.16, as far using the nightly build is OK for you. At least someone tests it... ;) But 2.3.16 should be released in weeks. Like, even on next week weekend or something. > If you have some guidelines or suggestions for starting the work on this patch, please let me know. I think above it was covered. But ask if something is unclear. > Thanks, > Darko > > --- On Thu, 10/8/09, Daniel Dekany <[hidden email]> wrote: > > From: Daniel Dekany <[hidden email]> > Subject: Re: [FreeMarker-user] Template Loaders and Acquisition Mechanism > To: "Darko Radosevic" <[hidden email]> > Cc: [hidden email] > Date: Thursday, October 8, 2009, 5:28 PM > > Thursday, October 8, 2009, 3:25:15 PM, Darko Radosevic wrote: > >> Hi, >> >> we have templates placed in folder hierarchy (default/client/site) >> and we're using default FileTemplateLoader and acquisition mechanism >> to load templates. But now we want to introduce a brand new type of >> templates - templates for mobile site. The mobile templates should >> follow this same default/client/site hierarchy but they should take >> precedence over regular templates when the request is coming from a >> mobile device. We could diferrentiate mobile templates by placing in >> separate folder or by "m_" name prefix, we haven't decided yet. So, >> loading order on a mobile site should be: >> >> 1. mobile site template 2.mobile client 3 mobile default 4.standard >> site 5 standard client 6.standard default >> >> This looks tricky to solve, I've first tried to utilize >> MultiTemplateLoader and some custom TemplateLoaders, but I would get only this loading order: >> >> 1. mobile site 2.standard site 3.mobile client 4. standard client >> 5. mobile default 6.standard default. >> >> The only working solution I've found so far is to use two >> Configurations, > > Don't do that, it's not how Configurations meant to be used. Templates > returned by one of the Configuration-s will search their dependences > using that Configuration. This also means that you will end up some > templates cached twice... and who knows what else I didn't realized > right now. > >> each having different base folder. In case 'mobile' >> Configuration throws FileNotFoundException, try to use 'standard' >> Configuration. The problem with this solution is that we'll need >> copy all templates from the 'standard' folder to the 'mobile' folder and then maintain duplicates. >> >> The only other possible solution I see is to rewrite TemplateCache >> to maybe somehow move acquisition mechanism inside template loader, >> but this looks way too low-level... > > You couldn't even do that there in a way so it will work correctly. > >> Do you know of any cases where TemplateCache is overwritten with >> some diferrent implementation, or do you know of some Freemarker >> features that could be useful for me? > > Maybe you can do the trick with the localization feature... like if > being mobile optimized would be a locale variation (you know, the > optional 3rd part of the locale string). Localization quite much does > what you need, in that it first tries to find the most locale-specific > template variation with acquisition, and only when that fails tries it > to find a less-specific one. > > Now if it doesn't work out well with localization, you can still > submit a patch. But then let's see what should be achieved... you want > to specify the target *media* here. It's very much like localization > right now, so it should look similarly: [hidden email], > [hidden email], [hidden email], etc. It's @ > because that's also what CSS uses for media selection, and it's also > suggestive: the page "at a mobile", "at a printer". I think the media > should have higher priority than locale, and that's also what you > wanted here. If a different need arises, we can still add a > media_priority setting. Yeah, and target_media itself is a new > setting. Pretty much like locale. > > Objections? > > Of course, you may ask for some guidance if you want to do the patch. > >> Thanks, >> Darko > -- Best regards, Daniel Dekany ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ FreeMarker-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/freemarker-user |
||||||||||||||||
Attila Szegedi-3
|
Okay, let me chime in a bit with my view of this... Locale used to be
a single customization we allowed, and one that follows naturally from the majority natural use of text generating systems - namely, generating text for human use; localization is a requirement for any modern text-processing system. Now, as soon as second classification arises (media type), I'm no longer so sure that we want to hardwire it too. Or hardwire locale anymore, except for backwards compatibility. Because, this indeed starts to sound as if it were becoming a general concept, isn't it? Together with the order of precedence, and eventual hierarchy of values (think of it - Locale values form a three-level hierarchy, and we actually have code recognize this and act accordingly). So, I'm thinking we should shoot for some general extensibility here instead of a quick patch. Even if this proved too hard, and we remained with a fixed set of customizations, I'd rather not add another argument to the findTemplateSource and any other methods that take a (String, Locale) tuple. For sake of future extensibility, we should have a class instead: public class TemplateSpecification { private String name; private Locale locale; private String targetMedia; } and have all methods that took a (String, Locale) pair now take an instance of TemplateSpecification (keeping the existing ones, but deprecating them). That way, we can compatibly extend it in future with multiple fields and not have to change the signature of the methods - any fields with null value mean "not specified". But I'd like to think a bit first about the direction of having a general mechanism - something where you can pass a Map (instead of TemplateSpecification), or maybe an URI, and have the components resolved as necessary. Attila. On 2009.10.15., at 12:33, Daniel Dekany wrote: > Wednesday, October 14, 2009, 6:44:06 PM, Darko Radosevic wrote: > >> Hi, >> >> thanks for the helpful response. >> >> I found some workarounds using the optional 3rd part of the locale >> string, but they have some limitations (must supply the mobile >> templates for each possible locale, or choose one locale and >> therefore make localization unusable). >> >> Now, about a possible patch. I'm interested in submitting the >> patch, but I have some questions. I know whether I need 'mobile' or >> 'standard' template at the time when I'm calling >> Configuration.getTemplate() method. Will this new 'target media' >> setting be an additional parameter in the getTemplate() method, or >> it will be new setting in Configuration? Or the setting in >> Configuration will be used to enable/disable this new target media >> lookup? > > The way these kind of things work is that (almost) all settings > defined on three levels, see: > http://freemarker.org/docs/pgui_config_settings.html > > So, the new target_media setting needs to be added on all 3 levels of > FreeMarker. > >> I guess we need to create an additional method similar to >> >> private Object findTemplateSource(String name, Locale locale) >> >> in TemplateCache, or modify this method. > > Yes, just add a new parameter, String targetMedium, etc. Also > TemplateCache.getTemplate will need an overloaded version (because the > original is public, it can't be changed), and > Configuration.getTemplate too... these are trivial to do too. The > template language may will need a new special-variable, .media, akin > of .locale, so it's again mostly just copy-paste. What else? I think > technically that's it. I will add the relevant parts to the > documentation. > >> I'm not familiar with the Freemarker development process, so I'd >> like to know what are the chances for this patch being >> accepted/rejected as a part of official Freemarker release? >> Do you know some approximate timeframe for this? I'm asking because >> this will have an impact on the project I'm working on. > > Inherently we are not bureaucratic and quite flexible and fast and > whatever, but let's see what are the extra hops: > > - Nowadays you can't contribute without signing a CLA. That's a paper > I send to you in e-mail (now), you sign it by hand, and post it to > us in snail mail. Yeah, it has to reach a Hungarian address. Sorry > about all that, but since big corps started to use FM... you know. > After we received the CLA, you get write access to the SVN repo, > fire up Eclipse (if you like), and just work and commit... we > automatically receive e-mail reports about the changes, so generally > you are not expected to ask before committing, as far as you are > working on the feature we know about. > > - Changes should be forward-ported to the 2.4 branch... Easy, but > still some boring extra work. > > - I didn't yet received any responses from the other two "heads", > regarding if they agree that this feature has place in FreeMarker. > If they don't respond soon, well... I think I will just assume it's > accepted. > > - You don't have to wait for 2.3.16, as far using the nightly build is > OK for you. At least someone tests it... ;) But 2.3.16 should be > released in weeks. Like, even on next week weekend or something. > >> If you have some guidelines or suggestions for starting the work on >> this patch, please let me know. > > I think above it was covered. But ask if something is unclear. > >> Thanks, >> Darko >> >> --- On Thu, 10/8/09, Daniel Dekany <[hidden email]> wrote: >> >> From: Daniel Dekany <[hidden email]> >> Subject: Re: [FreeMarker-user] Template Loaders and Acquisition >> Mechanism >> To: "Darko Radosevic" <[hidden email]> >> Cc: [hidden email] >> Date: Thursday, October 8, 2009, 5:28 PM >> >> Thursday, October 8, 2009, 3:25:15 PM, Darko Radosevic wrote: >> >>> Hi, >>> >>> we have templates placed in folder hierarchy (default/client/site) >>> and we're using default FileTemplateLoader and acquisition mechanism >>> to load templates. But now we want to introduce a brand new type of >>> templates - templates for mobile site. The mobile templates should >>> follow this same default/client/site hierarchy but they should take >>> precedence over regular templates when the request is coming from a >>> mobile device. We could diferrentiate mobile templates by placing in >>> separate folder or by "m_" name prefix, we haven't decided yet. So, >>> loading order on a mobile site should be: >>> >>> 1. mobile site template 2.mobile client 3 mobile default 4.standard >>> site 5 standard client 6.standard default >>> >>> This looks tricky to solve, I've first tried to utilize >>> MultiTemplateLoader and some custom TemplateLoaders, but I would >>> get only this loading order: >>> >>> 1. mobile site 2.standard site 3.mobile client 4. standard client >>> 5. mobile default 6.standard default. >>> >>> The only working solution I've found so far is to use two >>> Configurations, >> >> Don't do that, it's not how Configurations meant to be used. >> Templates >> returned by one of the Configuration-s will search their dependences >> using that Configuration. This also means that you will end up some >> templates cached twice... and who knows what else I didn't realized >> right now. >> >>> each having different base folder. In case 'mobile' >>> Configuration throws FileNotFoundException, try to use 'standard' >>> Configuration. The problem with this solution is that we'll need >>> copy all templates from the 'standard' folder to the 'mobile' >>> folder and then maintain duplicates. >>> >>> The only other possible solution I see is to rewrite TemplateCache >>> to maybe somehow move acquisition mechanism inside template loader, >>> but this looks way too low-level... >> >> You couldn't even do that there in a way so it will work correctly. >> >>> Do you know of any cases where TemplateCache is overwritten with >>> some diferrent implementation, or do you know of some Freemarker >>> features that could be useful for me? >> >> Maybe you can do the trick with the localization feature... like if >> being mobile optimized would be a locale variation (you know, the >> optional 3rd part of the locale string). Localization quite much does >> what you need, in that it first tries to find the most locale- >> specific >> template variation with acquisition, and only when that fails tries >> it >> to find a less-specific one. >> >> Now if it doesn't work out well with localization, you can still >> submit a patch. But then let's see what should be achieved... you >> want >> to specify the target *media* here. It's very much like localization >> right now, so it should look similarly: [hidden email], >> [hidden email], [hidden email], etc. It's @ >> because that's also what CSS uses for media selection, and it's also >> suggestive: the page "at a mobile", "at a printer". I think the media >> should have higher priority than locale, and that's also what you >> wanted here. If a different need arises, we can still add a >> media_priority setting. Yeah, and target_media itself is a new >> setting. Pretty much like locale. >> >> Objections? >> >> Of course, you may ask for some guidance if you want to do the patch. >> >>> Thanks, >>> Darko >> > > -- > Best regards, > Daniel Dekany ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ FreeMarker-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/freemarker-user |
||||||||||||||||
|
Daniel Dekany
|
Thursday, October 15, 2009, 2:46:16 PM, Attila Szegedi wrote:
> Okay, let me chime in a bit with my view of this... Locale used to be > a single customization we allowed, and one that follows naturally from > the majority natural use of text generating systems - namely, > generating text for human use; localization is a requirement for any > modern text-processing system. > > Now, as soon as second classification arises (media type), I'm no > longer so sure that we want to hardwire it too. Or hardwire locale > anymore, except for backwards compatibility. Because, this indeed > starts to sound as if it were becoming a general concept, isn't it? > Together with the order of precedence, and eventual hierarchy of > values (think of it - Locale values form a three-level hierarchy, and > we actually have code recognize this and act accordingly). So, I'm > thinking we should shoot for some general extensibility here instead > of a quick patch. Well, FM doesn't have a very flexible storage mechanism anyway (as it makes many assumptions (for exaple that's why it can't implement Zope-like acquisition)), but OK, why not do it a bit more flexible. I think it just should be a Map passed to getTemplate, plus a TemplateCache-level (Configuration-only setting for the user) list of keys, that thus specifies the precedences. Just a quick thought anyway. > Even if this proved too hard, and we remained with a fixed set of > customizations, I'd rather not add another argument to the > findTemplateSource and any other methods that take a (String, Locale) > tuple. For sake of future extensibility, we should have a class instead: > > public class TemplateSpecification { > private String name; > private Locale locale; > private String targetMedia; > } > > and have all methods that took a (String, Locale) pair now take an > instance of TemplateSpecification (keeping the existing ones, but > deprecating them). That way, we can compatibly extend it in future > with multiple fields and not have to change the signature of the > methods - any fields with null value mean "not specified". > > But I'd like to think a bit first about the direction of having a > general mechanism - something where you can pass a Map (instead of > TemplateSpecification), or maybe an URI, and have the components > resolved as necessary. > > Attila. > > On 2009.10.15., at 12:33, Daniel Dekany wrote: > >> Wednesday, October 14, 2009, 6:44:06 PM, Darko Radosevic wrote: >> >>> Hi, >>> >>> thanks for the helpful response. >>> >>> I found some workarounds using the optional 3rd part of the locale >>> string, but they have some limitations (must supply the mobile >>> templates for each possible locale, or choose one locale and >>> therefore make localization unusable). >>> >>> Now, about a possible patch. I'm interested in submitting the >>> patch, but I have some questions. I know whether I need 'mobile' or >>> 'standard' template at the time when I'm calling >>> Configuration.getTemplate() method. Will this new 'target media' >>> setting be an additional parameter in the getTemplate() method, or >>> it will be new setting in Configuration? Or the setting in >>> Configuration will be used to enable/disable this new target media >>> lookup? >> >> The way these kind of things work is that (almost) all settings >> defined on three levels, see: >> http://freemarker.org/docs/pgui_config_settings.html >> >> So, the new target_media setting needs to be added on all 3 levels of >> FreeMarker. >> >>> I guess we need to create an additional method similar to >>> >>> private Object findTemplateSource(String name, Locale locale) >>> >>> in TemplateCache, or modify this method. >> >> Yes, just add a new parameter, String targetMedium, etc. Also >> TemplateCache.getTemplate will need an overloaded version (because the >> original is public, it can't be changed), and >> Configuration.getTemplate too... these are trivial to do too. The >> template language may will need a new special-variable, .media, akin >> of .locale, so it's again mostly just copy-paste. What else? I think >> technically that's it. I will add the relevant parts to the >> documentation. >> >>> I'm not familiar with the Freemarker development process, so I'd >>> like to know what are the chances for this patch being >>> accepted/rejected as a part of official Freemarker release? >>> Do you know some approximate timeframe for this? I'm asking because >>> this will have an impact on the project I'm working on. >> >> Inherently we are not bureaucratic and quite flexible and fast and >> whatever, but let's see what are the extra hops: >> >> - Nowadays you can't contribute without signing a CLA. That's a paper >> I send to you in e-mail (now), you sign it by hand, and post it to >> us in snail mail. Yeah, it has to reach a Hungarian address. Sorry >> about all that, but since big corps started to use FM... you know. >> After we received the CLA, you get write access to the SVN repo, >> fire up Eclipse (if you like), and just work and commit... we >> automatically receive e-mail reports about the changes, so generally >> you are not expected to ask before committing, as far as you are >> working on the feature we know about. >> >> - Changes should be forward-ported to the 2.4 branch... Easy, but >> still some boring extra work. >> >> - I didn't yet received any responses from the other two "heads", >> regarding if they agree that this feature has place in FreeMarker. >> If they don't respond soon, well... I think I will just assume it's >> accepted. >> >> - You don't have to wait for 2.3.16, as far using the nightly build is >> OK for you. At least someone tests it... ;) But 2.3.16 should be >> released in weeks. Like, even on next week weekend or something. >> >>> If you have some guidelines or suggestions for starting the work on >>> this patch, please let me know. >> >> I think above it was covered. But ask if something is unclear. >> >>> Thanks, >>> Darko >>> >>> --- On Thu, 10/8/09, Daniel Dekany <[hidden email]> wrote: >>> >>> From: Daniel Dekany <[hidden email]> >>> Subject: Re: [FreeMarker-user] Template Loaders and Acquisition >>> Mechanism >>> To: "Darko Radosevic" <[hidden email]> >>> Cc: [hidden email] >>> Date: Thursday, October 8, 2009, 5:28 PM >>> >>> Thursday, October 8, 2009, 3:25:15 PM, Darko Radosevic wrote: >>> >>>> Hi, >>>> >>>> we have templates placed in folder hierarchy (default/client/site) >>>> and we're using default FileTemplateLoader and acquisition mechanism >>>> to load templates. But now we want to introduce a brand new type of >>>> templates - templates for mobile site. The mobile templates should >>>> follow this same default/client/site hierarchy but they should take >>>> precedence over regular templates when the request is coming from a >>>> mobile device. We could diferrentiate mobile templates by placing in >>>> separate folder or by "m_" name prefix, we haven't decided yet. So, >>>> loading order on a mobile site should be: >>>> >>>> 1. mobile site template 2.mobile client 3 mobile default 4.standard >>>> site 5 standard client 6.standard default >>>> >>>> This looks tricky to solve, I've first tried to utilize >>>> MultiTemplateLoader and some custom TemplateLoaders, but I would >>>> get only this loading order: >>>> >>>> 1. mobile site 2.standard site 3.mobile client 4. standard client >>>> 5. mobile default 6.standard default. >>>> >>>> The only working solution I've found so far is to use two >>>> Configurations, >>> >>> Don't do that, it's not how Configurations meant to be used. >>> Templates >>> returned by one of the Configuration-s will search their dependences >>> using that Configuration. This also means that you will end up some >>> templates cached twice... and who knows what else I didn't realized >>> right now. >>> >>>> each having different base folder. In case 'mobile' >>>> Configuration throws FileNotFoundException, try to use 'standard' >>>> Configuration. The problem with this solution is that we'll need >>>> copy all templates from the 'standard' folder to the 'mobile' >>>> folder and then maintain duplicates. >>>> >>>> The only other possible solution I see is to rewrite TemplateCache >>>> to maybe somehow move acquisition mechanism inside template loader, >>>> but this looks way too low-level... >>> >>> You couldn't even do that there in a way so it will work correctly. >>> >>>> Do you know of any cases where TemplateCache is overwritten with >>>> some diferrent implementation, or do you know of some Freemarker >>>> features that could be useful for me? >>> >>> Maybe you can do the trick with the localization feature... like if >>> being mobile optimized would be a locale variation (you know, the >>> optional 3rd part of the locale string). Localization quite much does >>> what you need, in that it first tries to find the most locale- >>> specific >>> template variation with acquisition, and only when that fails tries >>> it >>> to find a less-specific one. >>> >>> Now if it doesn't work out well with localization, you can still >>> submit a patch. But then let's see what should be achieved... you >>> want >>> to specify the target *media* here. It's very much like localization >>> right now, so it should look similarly: [hidden email], >>> [hidden email], [hidden email], etc. It's @ >>> because that's also what CSS uses for media selection, and it's also >>> suggestive: the page "at a mobile", "at a printer". I think the media >>> should have higher priority than locale, and that's also what you >>> wanted here. If a different need arises, we can still add a >>> media_priority setting. Yeah, and target_media itself is a new >>> setting. Pretty much like locale. >>> >>> Objections? >>> >>> Of course, you may ask for some guidance if you want to do the patch. >>> >>>> Thanks, >>>> Darko >>> >> >> -- >> Best regards, >> Daniel Dekany -- Best regards, Daniel Dekany ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ FreeMarker-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/freemarker-user |
||||||||||||||||
|
Darko Radosevic
|
------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ FreeMarker-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/freemarker-user |
|||||||||||||||||
|
Daniel Dekany
|
Friday, October 16, 2009, 1:39:33 PM, Darko Radosevic wrote:
> I think I follow your line of thought... Should these keys > configured for the map passed to getTemplate() be from a predefined > set of keys (so user can only configure keys offered by Freemarker, > like locale, @target_media), or custom keys would be allowed? > > Also, what naming convention do you think it should be used for > template names? The same like for locales, with _ separator? See the other mail I just sent before getting yours... > When you reach a consensus about the solution that's worth > investigating, you can let me know, and I could work on a 'test' > implementation to see how it works. I hope that will be within days. It seem to me that Attila is positive about the new feature, and Jonathan will bend if we say we want this... ;) > Regards, > Darko > > --- On Thu, 10/15/09, Daniel Dekany <[hidden email]> wrote: > > From: Daniel Dekany <[hidden email]> > Subject: Re: [FreeMarker-user] Template Loaders and Acquisition Mechanism > To: "Attila Szegedi" <[hidden email]> > Cc: "FreeMarker-user" <[hidden email]>, > "Darko Radosevic" <[hidden email]> > Date: Thursday, October 15, 2009, 8:01 PM > > Thursday, October 15, 2009, 2:46:16 PM, Attila Szegedi wrote: > >> Okay, let me chime in a bit with my view of this... Locale used to be >> a single customization we allowed, and one that follows naturally from >> the majority natural use of text generating systems - namely, >> generating text for human use; localization is a requirement for any >> modern text-processing system. >> >> Now, as soon as second classification arises (media type), I'm no >> longer so sure that we want to hardwire it too. Or hardwire locale >> anymore, except for backwards compatibility. Because, this indeed >> starts to sound as if it were becoming a general concept, isn't it? >> Together with the order of precedence, and eventual hierarchy of >> values (think of it - Locale values form a three-level hierarchy, and >> we actually have code recognize this and act accordingly). So, I'm >> thinking we should shoot for some general extensibility here instead >> of a quick patch. > > Well, FM doesn't have a very flexible storage mechanism anyway (as it > makes many assumptions (for exaple that's why it can't implement > Zope-like acquisition)), but OK, why not do it a bit more flexible. I > think it just should be a Map passed to getTemplate, plus a > TemplateCache-level (Configuration-only setting for the user) list of > keys, that thus specifies the precedences. Just a quick thought > anyway. > >> Even if this proved too hard, and we remained with a fixed set of >> customizations, I'd rather not add another argument to the >> findTemplateSource and any other methods that take a (String, Locale) >> tuple. For sake of future extensibility, we should have a class instead: >> >> public class TemplateSpecification { >> private String name; >> private Locale locale; >> private String targetMedia; >> } >> >> and have all methods that took a (String, Locale) pair now take an >> instance of TemplateSpecification (keeping the existing ones, but >> deprecating them). That way, we can compatibly extend it in future >> with multiple fields and not have to change the signature of the >> methods - any fields with null value mean "not specified". >> >> But I'd like to think a bit first about the direction of having a >> general mechanism - something where you can pass a Map (instead of >> TemplateSpecification), or maybe an URI, and have the components >> resolved as necessary. >> >> Attila. >> >> On 2009.10.15., at 12:33, Daniel Dekany wrote: >> >>> Wednesday, October 14, 2009, 6:44:06 PM, Darko Radosevic wrote: >>> >>>> Hi, >>>> >>>> thanks for the helpful response. >>>> >>>> I found some workarounds using the optional 3rd part of the locale >>>> string, but they have some limitations (must supply the mobile >>>> templates for each possible locale, or choose one locale and >>>> therefore make localization unusable). >>>> >>>> Now, about a possible patch. I'm interested in submitting the >>>> patch, but I have some questions. I know whether I need 'mobile' or >>>> 'standard' template at the time when I'm calling >>>> Configuration.getTemplate() method. Will this new 'target media' >>>> setting be an additional parameter in the getTemplate() method, or >>>> it will be new setting in Configuration? Or the setting in >>>> Configuration will be used to enable/disable this new target media >>>> lookup? >>> >>> The way these kind of things work is that (almost) all settings >>> defined on three levels, see: >>> http://freemarker.org/docs/pgui_config_settings.html >>> >>> So, the new target_media setting needs to be added on all 3 levels of >>> FreeMarker. >>> >>>> I guess we need to create an additional method similar to >>>> >>>> private Object findTemplateSource(String name, Locale locale) >>>> >>>> in TemplateCache, or modify this method. >>> >>> Yes, just add a new parameter, String targetMedium, etc. Also >>> TemplateCache.getTemplate will need an overloaded version (because the >>> original is public, it can't be changed), and >>> Configuration.getTemplate too... these are trivial to do too. The >>> template language may will need a new special-variable, .media, akin >>> of .locale, so it's again mostly just copy-paste. What else? I think >>> technically that's it. I will add the relevant parts to the >>> documentation. >>> >>>> I'm not familiar with the Freemarker development process, so I'd >>>> like to know what are the chances for this patch being >>>> accepted/rejected as a part of official Freemarker release? >>>> Do you know some approximate timeframe for this? I'm asking because >>>> this will have an impact on the project I'm working on. >>> >>> Inherently we are not bureaucratic and quite flexible and fast and >>> whatever, but let's see what are the extra hops: >>> >>> - Nowadays you can't contribute without signing a CLA. That's a paper >>> I send to you in e-mail (now), you sign it by hand, and post it to >>> us in snail mail. Yeah, it has to reach a Hungarian address. Sorry >>> about all that, but since big corps started to use FM... you know. >>> After we received the CLA, you get write access to the SVN repo, >>> fire up Eclipse (if you like), and just work and commit... we >>> automatically receive e-mail reports about the changes, so generally >>> you are not expected to ask before committing, as far as you are >>> working on the feature we know about. >>> >>> - Changes should be forward-ported to the 2.4 branch... Easy, but >>> still some boring extra work. >>> >>> - I didn't yet received any responses from the other two "heads", >>> regarding if they agree that this feature has place in FreeMarker. >>> If they don't respond soon, well... I think I will just assume it's >>> accepted. >>> >>> - You don't have to wait for 2.3.16, as far using the nightly build is >>> OK for you. At least someone tests it... ;) But 2.3.16 should be >>> released in weeks. Like, even on next week weekend or something. >>> >>>> If you have some guidelines or suggestions for starting the work on >>>> this patch, please let me know. >>> >>> I think above it was covered. But ask if something is unclear. >>> >>>> Thanks, >>>> Darko >>>> >>>> --- On Thu, 10/8/09, Daniel Dekany <[hidden email]> wrote: >>>> >>>> From: Daniel Dekany <[hidden email]> >>>> Subject: Re: [FreeMarker-user] Template Loaders and Acquisition >>>> Mechanism >>>> To: "Darko Radosevic" <[hidden email]> >>>> Cc: [hidden email] >>>> Date: Thursday, October 8, 2009, 5:28 PM >>>> >>>> Thursday, October 8, 2009, 3:25:15 PM, Darko Radosevic wrote: >>>> >>>>> Hi, >>>>> >>>>> we have templates placed in folder hierarchy (default/client/site) >>>>> and we're using default FileTemplateLoader and acquisition mechanism >>>>> to load templates. But now we want to introduce a brand new type of >>>>> templates - templates for mobile site. The mobile templates should >>>>> follow this same default/client/site hierarchy but they should take >>>>> precedence over regular templates when the request is coming from a >>>>> mobile device. We could diferrentiate mobile templates by placing in >>>>> separate folder or by "m_" name prefix, we haven't decided yet. So, >>>>> loading order on a mobile site should be: >>>>> >>>>> 1. mobile site template 2.mobile client 3 mobile default 4.standard >>>>> site 5 standard client 6.standard default >>>>> >>>>> This looks tricky to solve, I've first tried to utilize >>>>> MultiTemplateLoader and some custom TemplateLoaders, but I would >>>>> get only this loading order: >>>>> >>>>> 1. mobile site 2.standard site 3.mobile client 4. standard client >>>>> 5. mobile default 6.standard default. >>>>> >>>>> The only working solution I've found so far is to use two >>>>> Configurations, >>>> >>>> Don't do that, it's not how Configurations meant to be used. >>>> Templates >>>> returned by one of the Configuration-s will search their dependences >>>> using that Configuration. This also means that you will end up some >>>> templates cached twice... and who knows what else I didn't realized >>>> right now. >>>> >>>>> each having different base folder. In case 'mobile' >>>>> Configuration throws FileNotFoundException, try to use 'standard' >>>>> Configuration. The problem with this solution is that we'll need >>>>> copy all templates from the 'standard' folder to the 'mobile' >>>>> folder and then maintain duplicates. >>>>> >>>>> The only other possible solution I see is to rewrite TemplateCache >>>>> to maybe somehow move acquisition mechanism inside template loader, >>>>> but this looks way too low-level... >>>> >>>> You couldn't even do that there in a way so it will work correctly. >>>> >>>>> Do you know of any cases where TemplateCache is overwritten with >>>>> some diferrent implementation, or do you know of some Freemarker >>>>> features that could be useful for me? >>>> >>>> Maybe you can do the trick with the localization feature... like if >>>> being mobile optimized would be a locale variation (you know, the >>>> optional 3rd part of the locale string). Localization quite much does >>>> what you need, in that it first tries to find the most locale- >>>> specific >>>> template variation with acquisition, and only when that fails tries >>>> it >>>> to find a less-specific one. >>>> >>>> Now if it doesn't work out well with localization, you can still >>>> submit a patch. But then let's see what should be achieved... you >>>> want >>>> to specify the target *media* here. It's very much like localization >>>> right now, so it should look similarly: [hidden email], >>>> [hidden email], [hidden email], etc. It's @ >>>> because that's also what CSS uses for media selection, and it's also >>>> suggestive: the page "at a mobile", "at a printer". I think the media >>>> should have higher priority than locale, and that's also what you >>>> wanted here. If a different need arises, we can still add a >>>> media_priority setting. Yeah, and target_media itself is a new >>>> setting. Pretty much like locale. >>>> >>>> Objections? >>>> >>>> Of course, you may ask for some guidance if you want to do the patch. >>>> >>>>> Thanks, >>>>> Darko >>>> >>> >>> -- >>> Best regards, >>> Daniel Dekany > -- Best regards, Daniel Dekany ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ FreeMarker-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/freemarker-user |
||||||||||||||||
|
Daniel Dekany
|
In reply to this post
by Daniel Dekany
Thursday, October 15, 2009, 8:01:45 PM, Daniel Dekany wrote:
> I think it just should be a Map passed to getTemplate, plus a > TemplateCache-level (Configuration-only setting for the user) list > of keys, that thus specifies the precedences. Just a quick thought > anyway. Nah, not good. We have to truly understand some of the "variation tags", because we set settings in templates according them and like. Also we can't have true tags, because we only store the value of tags in the file names, which leads to ambiguities and hence some issues to address. So, I think we need something like this: public final class TemplateVariation { /** * Always use some special character before the values, but not @! * If you don't the setter will throw exception. */ @BeanProperty String[] mostImportantPostfixes; /** * Will use @ prefix in the file names, but you must start the * items with letter or digit when setting this. * E.g., String[]{"paper"}, String[]{"paper", "coated"}, etc., * will produce _@paper and _@paper_@coated, etc., in the * file name. */ @BeanProperty String[] targetMedia; /** * The only variation marker that uses no prefix in the file * name. */ @BeanProperty Locale locale; /** * Always use some special character before the values, but not @! * If you don't the setter will throw exception. */ @BeanProperty String[] lessImportantPostfixes; } So we have getTemplate(String name, TemplateVariation tv), which will somewhere do theTemplate.setLocale(tv.getLocale()) and theTemplate.setTargetMedia(tv.getTargetMedia()) when we got the Template. Also it should set @BeanProperty theTemplate.templateVariations, so the custom variation markers will be available, just like locale and targetMeida are. As of finding the best matching template, it should just construct List<String> finalPostfixList, which is the result of appending mostImportantPostfixes + targetMediaPrefixes + localePrefixes + tv.lessImportantPostfixes. So you end up with something like String[]{ "!foo", "!bar", "!baaz", "$mammal", "$wombat", "@mobile", "en", "US", "Mac", "~violet"} Easy. Also not the most generic, but then FreeMarker can't be that anyway without adding significant extra complexity to the public API. (OK, perhaps it could be, if we add a totally new storage API and then implement the current "rigid" one on top of that for BC... different topic.) Is this good enough for a FreeMarker, or should we complicate it a bit more? -- Best regards, Daniel Dekany ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ FreeMarker-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/freemarker-user |
||||||||||||||||
|
Daniel Dekany
|
Guys, we have to reach some consensus on this, or it won't make into
2.3.16. That thing really should be released, like, this weekend (if I will find time for it then.) (However, I'm still waiting for something regarding the detection of buggy Bean sequences. But if there won't be any, I might as well add an isBuggySequence method to that TempalteModel.) Anyway, I don't think it's a big problem if it doesn't make it into 2.3.16, as it can then go into the nightly, and surely Darko Radosevic can use that until 2.3.17 is out. Can you? As of my proposal, it needs some refinement. To recap, the base idea is that we simply construct a list of postfixes, and try finding the most specific file variation be repeatedly dropping the last prefix. As far as I see, the problem of the proposal is that it can't insert custom postfixes between the targetMedia and the locale. That could be solved by adding yet another String[] JavaBean property, but then what if we later add yet another predefined variation property... well, I guess we wont, but some may disagree. Also the proposal didn't address if what's if someone wants locale have higher priority than targetMedia... well, a Configuration-level setting could be added later for that, if it turns out to be useful. Last not least, obviously the most flexible solution would be if instead of a TemplateVariation the user can specify some kind of FileNamePrefixGenerator, which would generate the full, composite prefixes like "_!admin_@paper_en_US" directly, starting with the most desired one, going towards the less specific ones (which is maybe "_!member_@paper_en_US"; you noticed the custom logic there). But then querying the "tags" had to be solved too... etc. So we might as well go for the less flexible solution instead of hunting down an imaginary problem with abstraction bloat. (No, the problem of specifying custom ways of finding matching templates is not an imaginary problem at all, but like I said, solving that would require much deeper API changes than fiddling with these prefixes.) Friday, October 16, 2009, 1:48:21 PM, Daniel Dekany wrote: > Thursday, October 15, 2009, 8:01:45 PM, Daniel Dekany wrote: > >> I think it just should be a Map passed to getTemplate, plus a >> TemplateCache-level (Configuration-only setting for the user) list >> of keys, that thus specifies the precedences. Just a quick thought >> anyway. > > Nah, not good. We have to truly understand some of the "variation > tags", because we set settings in templates according them and like. > Also we can't have true tags, because we only store the value of tags > in the file names, which leads to ambiguities and hence some issues to > address. So, I think we need something like this: > > public final class TemplateVariation { > > /** > * Always use some special character before the values, but not @! > * If you don't the setter will throw exception. > */ > @BeanProperty String[] mostImportantPostfixes; > > /** > * Will use @ prefix in the file names, but you must start the > * items with letter or digit when setting this. > * E.g., String[]{"paper"}, String[]{"paper", "coated"}, etc., > * will produce _@paper and _@paper_@coated, etc., in the > * file name. > */ > @BeanProperty String[] targetMedia; > > /** > * The only variation marker that uses no prefix in the file > * name. > */ > @BeanProperty Locale locale; > > /** > * Always use some special character before the values, but not @! > * If you don't the setter will throw exception. > */ > @BeanProperty String[] lessImportantPostfixes; > > } > > So we have getTemplate(String name, TemplateVariation tv), which will > somewhere do theTemplate.setLocale(tv.getLocale()) and > theTemplate.setTargetMedia(tv.getTargetMedia()) when we got the > Template. Also it should set @BeanProperty > theTemplate.templateVariations, so the custom variation markers will > be available, just like locale and targetMeida are. > > As of finding the best matching template, it should just construct > List<String> finalPostfixList, which is the result of appending > mostImportantPostfixes + targetMediaPrefixes + localePrefixes + > tv.lessImportantPostfixes. > > So you end up with something like > > String[]{ > "!foo", "!bar", "!baaz", > "$mammal", "$wombat", > "@mobile", > "en", "US", "Mac", > "~violet"} > > Easy. Also not the most generic, but then FreeMarker can't be that > anyway without adding significant extra complexity to the public API. > (OK, perhaps it could be, if we add a totally new storage API and then > implement the current "rigid" one on top of that for BC... different > topic.) Is this good enough for a FreeMarker, or should we complicate > it a bit more? > -- Best regards, Daniel Dekany ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ FreeMarker-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/freemarker-user |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
