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