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
