>
> 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="[EMAIL PROTECTED]">...</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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
