> 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 <lothar_n...@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-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
