Thanks for your response. I think we're more or less on the same page about how to do this. I'm hoping for more specifics on how to do it with RIFE. More comment and questions below.
On Jul 17, 5:36 pm, Joshua Hansen <[EMAIL PROTECTED]> wrote: > [...] > But, if you must manage different templates for ltr and rtl, I'm > guessing you're going to have to manage separate skin files (XSL, PHP, > JSP, whatever) in any solution you decide upon. In that case, you can > code your element to use the selected locale for deciding which template > to load, and you will still get the benefit of RIFE's template system. That's what I was thinking too. And managing entire sets of files as a group also enables the clients to customize different interfaces if they want. (en_US and en_US_PDA, for example). But working with the jumpstart application, it didn't work quite the way I expected, hence my original posting. My thought was to move the contents of resources/templates down one additional directory, resulting in e.g.: resources/templates/en_US admin authentication common pub resources/templates/en_US_PDA admin authentication common pub resources/templates/fr etc, etc, etc. I then created a MyElement to extend Element and hold the skin attribute, and altered the elements to include the skin in the call to getHtmlTemplate(). But the jumpstart templates include other templates, and I haven't yet found a way to make them relative to the main template location. The intent of having a directory per skin is to put everything needed to create the UI in that skin in one place. That's easy to explain to customers, and easy to support. But it looks like making it work in RIFE means I need to find a different place than loading the element's template to identify to RIFE which directory to use. Any suggestions? > > > The customers change what data is available to be put on a > > page, but they can change where it is, or decide not to show some of > > the data the application makes available to them. Or add additional > > links, or a frameset, or whatever they want. > > I'm not sure if you meant 'customers _can_ change' or 'customers > _cannot_ change'. The logic and presentation separation in RIFE > templates would make it difficult (impossible?) for customers to change > data. Sorry, flying fingers don't keep up with thoughts all the time... Customers _cannot_ change what data is available to them, but they can choose not to display everything available. In a previous application with similar requirements, we met the requirement by creating a fully populated XML document, containing all the content (including labels) for the page. The HTML page was created via xsl transform from the populated document. The customers had complete access to the xsl for whatever customizations they wanted to make, but they could not make any change to the XML document that provided the content. And they could do whatever they wanted with CSS files, of course. One of the appeals of RIFE that has it on my short list to evaluate is the native support for xsl templating, so we can make use of our accumulated knowledge in transforms to create html. Thanks for your thoughts and ideas. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "rife-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rife-users?hl=en -~----------~----~----~----~------~----~------~--~---
