I'm still on Tapestry 3.0.3, but I adopted a conceptually similar
approach. When a page needs to transfer control to a different page, I
construct a navigator object, set its parameters, then route the navigator
object to a static navigation service that actually figures out which page
to invoke and how to set it up.
So far it's done wonders for simplifying my code in that my pages no
longer have to have references to one another. Plus it provides a global
pinch point where all navigation code flows which lets me enforce security
checks in one and only one place.
So far it turns out I only have about eight distinct "types" of
navigation. 80% of all navigation events are either "show a generic list of
records" or "show a specific record" which can be handled with two navigator
objects. I only need build a new navigator object if I need to make a more
complex transition.
--- Pat
> -----Original Message-----
> From: Aleksej [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 05, 2005 12:12 AM
> To: Tapestry users
> Subject: Application flow organization question
>
> Hello.
> I have lots pages in my application and most of them require some extra
> manipulations
> before usage. The simplest example is message page, which has
> setMessage( String ) method.
> Every time to display message I need to get that page object and in a
> second step to set message
> of this page. Instead of this, I made base page for all pages in my
> application and declare methods
> for all my pages such like IPage getMessagePage( String ) which gets
> Message page and sets
> it message. Many of such methods analizes they parameters and decide
> which page to return.
> For example, IPage getUserInfoPage( int userId ) will read user data and
> set it into user page and return
> this page, or will return allready defined message page with "user not
> found" message ( as example ).
> So, having such base page I don't even need to declare any methods in
> Page class, because they
> allready defined in it. But there is some problems with such
> organization. First of all, those methods
> are not accesible from custom Components becase they can't use my page
> base class as their base class
> because it must be AbstractComponent but not AbstractPage. This means
> that I must COPY-PASTE
> my code to some analogic class but from component hierarcy, and it is
> not very good I think.
> I allready heard some critics that Tapestry Page ans Component must be
> pure Beans constructed
> by hivemind or any other way, however I have no idea is it possible at
> all, but I am sure that it is quite
> complex task. So, currently I decided to solve this problem in a
> different way. The idea is to copy
> all those flow cotrolling methods to hivemind service, wire this service
> with current IRequestCycle
> and inject into each page which is interested in it ( into all pages in
> my case ). As I understand such service
> must be threaded and I must inject current thread IRequestCycle in it.
> In general, I need to know how to
> inject current request cycle into any service. The trick here is that in
> page must be injected service which
> allready has injected THAT page IRequestCycle :) Is it possible? I think
> that it is, but not sure about
> realization. Something like this or maybe other way?
> hivemodule.xml
> <implementation service-id="navigator">
> <invoke-factory model="threaded">
> <construct class="service.NavigatorImpl">
> <set-object property="requestCycle" object="???" />
> </construct>
> </invoke-factory>
> </implementation>
>
> *.page
> <inject property="navigator" object="service:navigator" />
>
> Also, what do you thing about app flow organization?
>
>
> ---------------------------------------------------------------------
> 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]
