How to handle customer versions of Tapestry pages?

NAVIGATION

CATEGORIES

Java

REFERRENCE

If you have some good idea, Cilck and mail to us please...

LINKS

Home » Java

How to handle customer versions of Tapestry pages?
5 answers - 1688 bytes -
Hello.
We develop a product using Tapestry 3.0.4.
For our different customers, parts of the pages need to differ while the
overall structure is the same. This begins with having different images in the
@Border for branding and goes on with e.g. form fields only present in versions
for some customers.
We assume the best way to handle those different parts of the pages by using
special components and letting Tapestry use the correct one for the version.
Which component to use we want to decide declaratively e.g. in some XML
file.
For one version, always the same component version is used, so there should be
no problems with Tapestry's page cache.
A few conditions make this not a trivial task, it seems: We cannot use @Block
and @RenderBlock, because the components for versions of other customers shall
not be contained in the deployment (at worst they could contain corporate
secrets).
We want to be able to continue using Spindle for development while of course
that would probably only be possible for a default version of each
component.
We tried using an ISpecificationResolverDelegate, but unfortunately that gets
asked only when Tapestry is not able to locate a component by its standard
means. This way always the default component would be used and we have no way
of dynamically specifying another
version.
For testing purposes we patched () and
that works just as we want, but we would rather use an unpatched Tapestry.
Is there some way doing the above described thing in a standard way that we
miss?
Regards and thanks in advance,
Markus
No.1 | | 2022 bytes | |
Part of our plan is to swap in and out Tapestry Libraries. per "customer".

hth,

Mark

Message
From: lornamas (AT) gmx (DOT) net [mailto:lornamas (AT) gmx (DOT) net]
Sent: Fri 6/16/2006 4:54 PM
To: users (AT) tapestry (DOT) apache.org
Subject: How to handle customer versions of Tapestry pages?

Hello.

We develop a product using Tapestry 3.0.4.

For our different customers, parts of the pages need to differ while the
overall structure is the same. This begins with having different images in the
@Border for branding and goes on with e.g. form fields only present in versions
for some customers.

We assume the best way to handle those different parts of the pages by using
special components and letting Tapestry use the correct one for the version.
Which component to use we want to decide declaratively e.g. in some XML
file.

For one version, always the same component version is used, so there should be
no problems with Tapestry's page cache.

A few conditions make this not a trivial task, it seems: We cannot use @Block
and @RenderBlock, because the components for versions of other customers shall
not be contained in the deployment (at worst they could contain corporate
secrets).

We want to be able to continue using Spindle for development while of course
that would probably only be possible for a default version of each
component.

We tried using an ISpecificationResolverDelegate, but unfortunately that gets
asked only when Tapestry is not able to locate a component by its standard
means. This way always the default component would be used and we have no way
of dynamically specifying another
version.

For testing purposes we patched () and
that works just as we want, but we would rather use an unpatched Tapestry.

Is there some way doing the above described thing in a standard way that we
miss?

Regards and thanks in advance,
Markus
No.2 | | 1968 bytes | |

A few conditions make this not a trivial task, it seems: We cannot use @Block
and @RenderBlock, because the components for versions of other customers shall
not be contained in the deployment (at worst they could contain corporate
secrets).

Why not @Block/@RenderBlock? In fact, these seem ideal for your
situation. So, you're grabbing the right component instance based on
the current customer, right? And some of these customer-specific
components have sensitive information, and so they shouldn't be
distributed to all customers, right? No sweat. :)
Define -
A page per customer
Define -
The customer specific components in blocks within the customer specific
page

Distribute -
The application pages + the Customer's component page.

Now, when you need to grab that component, you do something like the
following:

html:
<div jwcid="@RenderBlock" block="ognl:customerBlock"/>

<div jwcid="DefaultBLock@Block"></div>

java:

public IComponent getCustomerBlock() {
/*I'm assuming you're using tap 4 and the customer object is injected*/
Customer c = getCustomer();
IPage p = getRequestCycle().getPage(c.getCustomerPageName()) ;
IComponent block = p.getComponent("BlockName or lookup here");
if (block == null) {
return getPage().getComponent("DefaultBlock");
}
}

Something like that. The point is, RenderBlock doesn't care where the
Block is coming from; it doesn't /have/ to be on the same page. This
allows you to isolate customer-specific blocks on a page for that
customer, and then only distribute the appropriate customer-specific
page. So I ask again: why not Block/RenderBlock? :)

Robert

To unsubscribe, e-mail: users-unsubscribe (AT) tapestry (DOT) apache.org
For additional commands, e-mail: users-help (AT) tapestry (DOT) apache.org
No.3 | | 2830 bytes | |
more note at develop time, using Spindle, you'll have all
components and all component definitions available and Spindle will be
happy. At runtime, not only will you only include the Customer specific
page, but also the customer specific components; Tapestry will be
"happy" because it will never reference a page which contains unknown
components.

(Although, if you're using tap3 and you're using folder hierarchies for
your components, you'll have to make sure that your .application doesn't
reference other-customer components).

Robert

Robert Zeigler wrote:
>A few conditions make this not a trivial task, it seems: We cannot use @Block
>and @RenderBlock, because the components for versions of other customers shall
>not be contained in the deployment (at worst they could contain corporate
>secrets).
>>

Why not @Block/@RenderBlock? In fact, these seem ideal for your
situation. So, you're grabbing the right component instance based on
the current customer, right? And some of these customer-specific
components have sensitive information, and so they shouldn't be
distributed to all customers, right? No sweat. :)
Define -
A page per customer
Define -
The customer specific components in blocks within the customer specific
page

Distribute -
The application pages + the Customer's component page.

Now, when you need to grab that component, you do something like the
following:

.html:
<div jwcid="@RenderBlock" block="ognl:customerBlock"/>

<div jwcid="DefaultBLock@Block"></div>

.java:

public IComponent getCustomerBlock() {
/*I'm assuming you're using tap 4 and the customer object is injected*/
Customer c = getCustomer();
IPage p = getRequestCycle().getPage(c.getCustomerPageName()) ;
IComponent block = p.getComponent("BlockName or lookup here");
if (block == null) {
return getPage().getComponent("DefaultBlock");
}
}

Something like that. The point is, RenderBlock doesn't care where the
Block is coming from; it doesn't /have/ to be on the same page. This
allows you to isolate customer-specific blocks on a page for that
customer, and then only distribute the appropriate customer-specific
page. So I ask again: why not Block/RenderBlock? :)

Robert

To unsubscribe, e-mail: users-unsubscribe (AT) tapestry (DOT) apache.org
For additional commands, e-mail: users-help (AT) tapestry (DOT) apache.org

To unsubscribe, e-mail: users-unsubscribe (AT) tapestry (DOT) apache.org
For additional commands, e-mail: users-help (AT) tapestry (DOT) apache.org
No.4 | | 373 bytes | |
Hello.

Sorry for not answering earlier and many thanks for your detailed answer.

I did not think of the possibility to get the @Blocks from a different page that would not be used for display itself.

Using @RenderBlock and @Block puts in one more indirection than the (not standard) way we tried before, but I think we can live with that.

Markus
No.5 | | 373 bytes | |
Hello.

Sorry for not answering earlier and many thanks for your detailed answer.

I did not think of the possibility to get the @Blocks from a different page that would not be used for display itself.

Using @RenderBlock and @Block puts in one more indirection than the (not standard) way we tried before, but I think we can live with that.

Markus

Re: How to handle customer versions of Tapestry pages?

EMSDN.COM

Archive for 'How to handle customer versions of Tapestry pages?' by lornamas

Java

How to handle customer versions of Tapestry pages?