You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by t5_lothar <lo...@gmx.de> on 2010/07/06 11:27:41 UTC

[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.

These are my ideas:

(1) If/Else approch: <t:if test=${customerA}> ... display some fields ...
<p:else> ... display other fields ... </p:else> </t:if>

(2) CSS Approch: <div class="customerA"> ... some fields ...</div> 
  <div class="customerB"> ... other fields ...</div>  and set one of the
styles as 'display:none'.

(3) Page inheritance approch: Put the common stuff in a BasePage and build
two customer dependent variants inheriting from it. Don't know exactly if
this supported by Tapestry.

(4) Component approch: Put the common stuff in a component and have to
specialized pages use this component. 

Any suggestions, possibliy new ideas?

Thanks,
Lothar
-- 
View this message in context: http://old.nabble.com/-T5--Best-practices-for-customer-specific-code-in-pages-tp29083515p29083515.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


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

Posted by t5_lothar <lo...@gmx.de>.
... 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-specific-code-in-pages-tp29083515p29098666.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


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

Posted by t5_lothar <lo...@gmx.de>.
Thanks for your valuable input. I really appreciate it.

Just to clarify: I am talking about different deployments for each of the
customers. I was thinking of setting the LANG=de_DE_<customer-id>  in the
environment and having a service evaluate that.

Lothar


Josh Canfield wrote:
> 
>> I am using Tapestry in a product that will be used by multiple customers.
> 
> The approaches you've listed require you to modify the source code in
> order to scale up the supported customers. If you want to add
> customers to the application without modifying code then I'd change to
> test for specific options that the customer has selected.
> 
>> (1) If/Else approch:
> Looking at the problem as rendering options instead of by customer I
> think this is a good choice. You can span options across
> pages/components either by passing them down through parameters or
> putting them in the environment when the page is rendering.
> 
> <div t:type="if" test="options.showOptionalButton" class="button
> optional-button">
> <t:eventLink event="optionalButtonEvent" context="theObject">Optional
> Button</t:eventLink>
> </div>
> 
>> (2) CSS Approch:
> Don't put anything in the HTML sent to a client that you don't want to
> get used by the client.
> 
>> (3) Page inheritance approch:
> I tend to believe in a more database driven approach for customization
> within a single deployment. Of course, I don't do the type of work
> where your two customers are the sales department and the marketing
> department and will only ever be those two departments.
> 
>> (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
> 
> On Tue, Jul 6, 2010 at 2:27 AM, t5_lothar <lo...@gmx.de> wrote:
>>
>> 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.
>>
>> These are my ideas:
>>
>> (1) If/Else approch: <t:if test=${customerA}> ... display some fields ...
>> <p:else> ... display other fields ... </p:else> </t:if>
>>
>> (2) CSS Approch: <div class="customerA"> ... some fields ...</div>
>>  <div class="customerB"> ... other fields ...</div>  and set one of the
>> styles as 'display:none'.
>>
>> (3) Page inheritance approch: Put the common stuff in a BasePage and
>> build
>> two customer dependent variants inheriting from it. Don't know exactly if
>> this supported by Tapestry.
>>
>> (4) Component approch: Put the common stuff in a component and have to
>> specialized pages use this component.
>>
>> Any suggestions, possibliy new ideas?
>>
>> Thanks,
>> Lothar
>> --
>> View this message in context:
>> http://old.nabble.com/-T5--Best-practices-for-customer-specific-code-in-pages-tp29083515p29083515.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
> 
> 
> 
> -- 
> --
> http://www.bodylabgym.com - a private, by appointment only, one-on-one
> health and fitness facility.
> --
> http://www.ectransition.com - Quality Electronic Cigarettes at a
> reasonable price!
> --
> TheDailyTube.com. Sign up and get the best new videos on the internet
> delivered fresh to your inbox.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/-T5--Best-practices-for-customer-specific-code-in-pages-tp29083515p29093988.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


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

Posted by Josh Canfield <jo...@gmail.com>.
> I am using Tapestry in a product that will be used by multiple customers.

The approaches you've listed require you to modify the source code in
order to scale up the supported customers. If you want to add
customers to the application without modifying code then I'd change to
test for specific options that the customer has selected.

> (1) If/Else approch:
Looking at the problem as rendering options instead of by customer I
think this is a good choice. You can span options across
pages/components either by passing them down through parameters or
putting them in the environment when the page is rendering.

<div t:type="if" test="options.showOptionalButton" class="button
optional-button">
<t:eventLink event="optionalButtonEvent" context="theObject">Optional
Button</t:eventLink>
</div>

> (2) CSS Approch:
Don't put anything in the HTML sent to a client that you don't want to
get used by the client.

> (3) Page inheritance approch:
I tend to believe in a more database driven approach for customization
within a single deployment. Of course, I don't do the type of work
where your two customers are the sales department and the marketing
department and will only ever be those two departments.

> (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

On Tue, Jul 6, 2010 at 2:27 AM, t5_lothar <lo...@gmx.de> wrote:
>
> 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.
>
> These are my ideas:
>
> (1) If/Else approch: <t:if test=${customerA}> ... display some fields ...
> <p:else> ... display other fields ... </p:else> </t:if>
>
> (2) CSS Approch: <div class="customerA"> ... some fields ...</div>
>  <div class="customerB"> ... other fields ...</div>  and set one of the
> styles as 'display:none'.
>
> (3) Page inheritance approch: Put the common stuff in a BasePage and build
> two customer dependent variants inheriting from it. Don't know exactly if
> this supported by Tapestry.
>
> (4) Component approch: Put the common stuff in a component and have to
> specialized pages use this component.
>
> Any suggestions, possibliy new ideas?
>
> Thanks,
> Lothar
> --
> View this message in context: http://old.nabble.com/-T5--Best-practices-for-customer-specific-code-in-pages-tp29083515p29083515.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>



-- 
--
http://www.bodylabgym.com - a private, by appointment only, one-on-one
health and fitness facility.
--
http://www.ectransition.com - Quality Electronic Cigarettes at a
reasonable price!
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


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

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 06 Jul 2010 06:27:41 -0300, t5_lothar <lo...@gmx.de> wrote:

> Hi all,

Hi!

> (1) If/Else approch: <t:if test=${customerA}> ... display some fields ...
> <p:else> ... display other fields ... </p:else> </t:if>

1) Never use expansions in parameters. It coerces the value to a String.
2) This approach tends to get unmaintainable in the long run.

> (2) CSS Approch: <div class="customerA"> ... some fields ...</div>
>   <div class="customerB"> ... other fields ...</div>  and set one of the
> styles as 'display:none'.

This has the potential of opening security holes.

> (3) Page inheritance approch: Put the common stuff in a BasePage and  
> build two customer dependent variants inheriting from it. Don't know  
> exactly if
> this supported by Tapestry.

It is. You'll need URL rewriting or advising some ComponentClassResolver  
methods to do that. Template-wise, the documentation is here:  
http://tapestry.apache.org/tapestry5.1/guide/templates.html, section  
Template Inheritance.

> (4) Component approch: Put the common stuff in a component and have to
> specialized pages use this component.

It's approach with good reusability.

-- 
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


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

Posted by "Juan E. Maya" <ma...@gmail.com>.
I recommend you to check the way the BeanEditForm Works. U might
dynamically use a strategy to create the beanModels for a specific
form. Even if this doesn't apply directly u can get very good ideas
from the source code of the BeanEditForm

On Tue, Jul 6, 2010 at 11:27 AM, t5_lothar <lo...@gmx.de> wrote:
>
> 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.
>
> These are my ideas:
>
> (1) If/Else approch: <t:if test=${customerA}> ... display some fields ...
> <p:else> ... display other fields ... </p:else> </t:if>
>
> (2) CSS Approch: <div class="customerA"> ... some fields ...</div>
>  <div class="customerB"> ... other fields ...</div>  and set one of the
> styles as 'display:none'.
>
> (3) Page inheritance approch: Put the common stuff in a BasePage and build
> two customer dependent variants inheriting from it. Don't know exactly if
> this supported by Tapestry.
>
> (4) Component approch: Put the common stuff in a component and have to
> specialized pages use this component.
>
> Any suggestions, possibliy new ideas?
>
> Thanks,
> Lothar
> --
> View this message in context: http://old.nabble.com/-T5--Best-practices-for-customer-specific-code-in-pages-tp29083515p29083515.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org