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