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]
