You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Ashish Raniwala <ar...@gmail.com> on 2005/06/10 06:26:45 UTC
Tapestry Components
Hi Erik,
I have a design issue and our team need some guidelines on what functionality should be written as component and what should be page?
General guideline is, follow DRY and make everything which is re usable as component. But we have some complex cases where it is getting difficult.
I want to validate that we are not voilating basic rules of tapestry.
Background:
We have Tab representation in our UI and the UI metaphor is such that first tab is View/Edit of entity and rest all tabs are view/edit of its associations.
So when we come from our list page we go to view page of selected entity and user can click on tabs to view/edit associations.
Problem:
Should we make tab as a component ?
Challanges:
Generic tab component will have no way to pass parameters (set property) to any page.
Proposed solution:
Tab component may set object to Visit and target page pull objects from Visit.
This solution works but it is not clean as we will not be able to clean Visit object because user may click on next tab in which case we will need the object from Visit.
Alternatively User may click on menus (Pagelinks) and may take some alternate flow in which case Visit remains dirty (Ofcourse we can have checkpoints to empty Visit). My feeling is that this solution has loose binding of pages like traditional web developement which tapestry try to fix and this may not be scalable solution.
I looked at the Workbench example of tab which uses RenderBlock. That solution will not work for us as all View/Edit pages will become components in that case and clicking an Edit button in component will have to tell the container page that what is the next block to be rendered.
Please suggest what is the right approach ?
Should we implement tabs in each page or make as component? If you are in favour of making it as component, how it should be implemented?
Let me know if you want to see the UI ?
Thanks,
Ashish
Re: Tapestry Components
Posted by Ron Piterman <mp...@vollbio.de>.
And, ofcouse, Tabs should defenitley be a component.
ציטוט Ashish Raniwala:
> Hi Erik,
> I have a design issue and our team need some guidelines on what functionality should be written as component and what should be page?
> General guideline is, follow DRY and make everything which is re usable as component. But we have some complex cases where it is getting difficult.
> I want to validate that we are not voilating basic rules of tapestry.
>
> Background:
> We have Tab representation in our UI and the UI metaphor is such that first tab is View/Edit of entity and rest all tabs are view/edit of its associations.
> So when we come from our list page we go to view page of selected entity and user can click on tabs to view/edit associations.
>
> Problem:
> Should we make tab as a component ?
>
> Challanges:
> Generic tab component will have no way to pass parameters (set property) to any page.
>
> Proposed solution:
> Tab component may set object to Visit and target page pull objects from Visit.
> This solution works but it is not clean as we will not be able to clean Visit object because user may click on next tab in which case we will need the object from Visit.
> Alternatively User may click on menus (Pagelinks) and may take some alternate flow in which case Visit remains dirty (Ofcourse we can have checkpoints to empty Visit). My feeling is that this solution has loose binding of pages like traditional web developement which tapestry try to fix and this may not be scalable solution.
>
>
> I looked at the Workbench example of tab which uses RenderBlock. That solution will not work for us as all View/Edit pages will become components in that case and clicking an Edit button in component will have to tell the container page that what is the next block to be rendered.
>
> Please suggest what is the right approach ?
>
> Should we implement tabs in each page or make as component? If you are in favour of making it as component, how it should be implemented?
> Let me know if you want to see the UI ?
>
> Thanks,
> Ashish
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry Components
Posted by Ashish Raniwala <ar...@gmail.com>.
Hi Ron,
Thanks for help. The solution seems to be promising.
Last mail I replied from a old mail which I wrote to Erik and forgot to
remove his name.
Intentionally I was not looking for Erik only.
Thanks,
Ashish
----- Original Message -----
From: "Ron Piterman" <mp...@vollbio.de>
To: <ta...@jakarta.apache.org>
Sent: Friday, June 10, 2005 6:25 PM
Subject: Re: Tapestry Components
> Well, I am not called erik, but I will give it a shot...
> You could use the visit for the exchange.
> You could also use the Tab to render Blocks inside one page, so you don't
> switch pages, just "views".
> finally, if you keep to the "switch pages", you could add your tab
> component a data-exchange parameter, which will be get and set from and to
> pages:
>
> public abstract void getExchangeParamName();
>
>
> public void switchTab(IRequestCycle cycle) {
> ...
> Object ex = Ognl.getValue(getExchangeParamName(), getPage());
> Ognl.setValue(getExchangeParamName(), newPage, ex);
> ...
> }
>
> so before switching to the "selected" tab, the pages "shake hands"...
>
> Cheers,
> Ron
>
>
> ציטוט Ashish Raniwala:
>> Hi Erik,
>> I have a design issue and our team need some guidelines on what
>> functionality should be written as component and what should be page?
>> General guideline is, follow DRY and make everything which is re usable
>> as component. But we have some complex cases where it is getting
>> difficult.
>> I want to validate that we are not voilating basic rules of tapestry.
>>
>> Background:
>> We have Tab representation in our UI and the UI metaphor is such that
>> first tab is View/Edit of entity and rest all tabs are view/edit of its
>> associations.
>> So when we come from our list page we go to view page of selected entity
>> and user can click on tabs to view/edit associations.
>>
>> Problem:
>> Should we make tab as a component ? Challanges:
>> Generic tab component will have no way to pass parameters (set property)
>> to any page.
>>
>> Proposed solution:
>> Tab component may set object to Visit and target page pull objects from
>> Visit.
>> This solution works but it is not clean as we will not be able to clean
>> Visit object because user may click on next tab in which case we will
>> need the object from Visit.
>> Alternatively User may click on menus (Pagelinks) and may take some
>> alternate flow in which case Visit remains dirty (Ofcourse we can have
>> checkpoints to empty Visit). My feeling is that this solution has loose
>> binding of pages like traditional web developement which tapestry try to
>> fix and this may not be scalable solution.
>>
>>
>> I looked at the Workbench example of tab which uses RenderBlock. That
>> solution will not work for us as all View/Edit pages will become
>> components in that case and clicking an Edit button in component will
>> have to tell the container page that what is the next block to be
>> rendered.
>>
>> Please suggest what is the right approach ?
>>
>> Should we implement tabs in each page or make as component? If you are in
>> favour of making it as component, how it should be implemented?
>> Let me know if you want to see the UI ?
>>
>> Thanks,
>> Ashish
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry Components
Posted by Ron Piterman <mp...@vollbio.de>.
Well, I am not called erik, but I will give it a shot...
You could use the visit for the exchange.
You could also use the Tab to render Blocks inside one page, so you
don't switch pages, just "views".
finally, if you keep to the "switch pages", you could add your tab
component a data-exchange parameter, which will be get and set from and
to pages:
public abstract void getExchangeParamName();
public void switchTab(IRequestCycle cycle) {
...
Object ex = Ognl.getValue(getExchangeParamName(), getPage());
Ognl.setValue(getExchangeParamName(), newPage, ex);
...
}
so before switching to the "selected" tab, the pages "shake hands"...
Cheers,
Ron
ציטוט Ashish Raniwala:
> Hi Erik,
> I have a design issue and our team need some guidelines on what functionality should be written as component and what should be page?
> General guideline is, follow DRY and make everything which is re usable as component. But we have some complex cases where it is getting difficult.
> I want to validate that we are not voilating basic rules of tapestry.
>
> Background:
> We have Tab representation in our UI and the UI metaphor is such that first tab is View/Edit of entity and rest all tabs are view/edit of its associations.
> So when we come from our list page we go to view page of selected entity and user can click on tabs to view/edit associations.
>
> Problem:
> Should we make tab as a component ?
>
> Challanges:
> Generic tab component will have no way to pass parameters (set property) to any page.
>
> Proposed solution:
> Tab component may set object to Visit and target page pull objects from Visit.
> This solution works but it is not clean as we will not be able to clean Visit object because user may click on next tab in which case we will need the object from Visit.
> Alternatively User may click on menus (Pagelinks) and may take some alternate flow in which case Visit remains dirty (Ofcourse we can have checkpoints to empty Visit). My feeling is that this solution has loose binding of pages like traditional web developement which tapestry try to fix and this may not be scalable solution.
>
>
> I looked at the Workbench example of tab which uses RenderBlock. That solution will not work for us as all View/Edit pages will become components in that case and clicking an Edit button in component will have to tell the container page that what is the next block to be rendered.
>
> Please suggest what is the right approach ?
>
> Should we implement tabs in each page or make as component? If you are in favour of making it as component, how it should be implemented?
> Let me know if you want to see the UI ?
>
> Thanks,
> Ashish
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry Components
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Jun 10, 2005, at 12:26 AM, Ashish Raniwala wrote:
> Hi Erik,
This is a public list - no need to address anyone in particular here.
> I have a design issue and our team need some guidelines on what
> functionality should be written as component and what should be page?
> General guideline is, follow DRY and make everything which is re
> usable as component. But we have some complex cases where it is
> getting difficult.
> I want to validate that we are not voilating basic rules of tapestry.
There are no rules. Do what feels right. If you are copy/pasting
code, then back up and componentize or centralize. If you're not,
then keep cruising.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org