Re: [T5] Best practices for customer-specific code in pages

... in the meantime I found this interesting posting which goes in the same direction: http://old.nabble.com/-T5--How-to-%22skin%22-.properties-files--Localization-almost-good...-tp15843698p15845508.html -- View this message in context: http://old.nabble.com/-T5--Best-practices-for-customer-spe

Re: [T5] How to "skin" .properties files? Localization almost good...

This approach sounds really promising and works out well for templates. But how about properties? As the author said, something similiar can be used for properties. However, I have difficulties in finding the equivalent... Andreas Pardeike-2 wrote: > > On 5 mar 2008, at 06.46, Vjeran Marcinko w

Re: [T5] Best practices for customer-specific code in pages

>> (4) Component approch: > If you have parts of your page that do independent rendering/computing > that either makes your page design cleaner, or allows you to use that > functionality elsewhere then definitely put it in a component. > > > Have fun! > Josh > >

[T5] Best practices for customer-specific code in pages

Hi all, I am using Tapestry in a product that will be used by multiple customers. There will slight alterations in the pages depending on the customer's preference like a few more edit fields, additional buttons etc. My question is how to handle these variations of one page the most elegantly. T

Re: Using PropertyEditor standalone

wrote: > > On Wed, 09 Jun 2010 09:46:50 -0300, t5_lothar wrote: > >> Hello all, > > Hi! > >> my goal is to create something like BeanEditForm, but the underlying >> data is not a Java Bean but a an XML tree (org.jdom.Element). > > Why don't you u

Using PropertyEditor standalone

Hello all, my goal is to create something like BeanEditForm, but the underlying data is not a Java Bean but a an XML tree (org.jdom.Element). I found out that the core component being responsible for the field editing is PropertyEditor. My idea is to use PropertyEditor standalone.