Model 3? Can you elaborate on this one?
> -----Original Message-----
> From: A mailing list about Java Server Pages specification and reference
> [mailto:[EMAIL PROTECTED]]On Behalf Of Daniel Lopez
> Sent: Friday, May 05, 2000 1:19 AM
> To: [EMAIL PROTECTED]
> Subject: Re: model 2 servlet mapping question
>
>
> Hi,
>
> I'm not sure whether I was the one or not(who cares? ;)) But you are
> right in the sense that I already talked about that. In our framework
> (WebLeaf) the configuration of an Operation might look like that:
> <OPERATION
> NAME = "OpertaionName"
> DESCRIPTION = "Decription of the operation. Documentation
> purposes."
> CLASSNAME = "test.OperationImplementation"
> UI_PATH = "/DefaultPageToForward.jsp"
> PARAMETER_ERROR_PATH = "/WrongParametersForwardPage.jsp"
> OPERATION_ERROR_PATH = "/SomethingWrongExecutingForwardPage.jsp"
> >
> <PROPERTY NAME="DYNAMIC_URL_PREFIX" VALUE="/dir/" />
> <OPERATION>
>
> If everything goes fine, control is forwarded to UI_PATH; if something
> went wrong while setting the parameters of your action class, it is
> forwarded to PARAMETER_ERROR_PATH; if something went wrong while
> executing your action, it is forwarded to OPERATION_ERROR_PATH. Lastly,
> if you want to override this default behaviour, then you just have to
> specify the desired URL either in the Result object of performing your
> action (Normal behaviour) or in the exception thrown from your action
> methods (in abnormal operation result). In this case you can generate
> your URL on the fly and if you use operation properties, as in the
> sample shown above, the hardcoded part can be minimal. Oh, as a last
> goodie, the default error URLs can be specified at application level and
> then overriden, or not, for each specific operation, as shown above.
> Tha means that flow control and physical names of the URLs are pretty
> much independent of the action classes themselves. I have to admit we
> are pretty happy with it :).
>
> We haven't yet used the state-machine approach but I'm glad you found it
> useful, Andrew. One of the goodies of this approach is that the kernel
> of your machine can be reused and it is minimal so debugging that part
> is much easier.
>
> Craig, if you'd like to get more info about what we do, let me know as
> the WebLeaf framework has been evolving lately but I don't update the
> web site because nobody seems to be interested and our main focus is to
> use it ourselves.
>
> Just my 2c,
> Dan
> PD: I'd like to answer some other interesting postings lately regarding
> security and model 2, but eastern holidays(10 days) and "model 3"
> development have kept me very busy.
> -------------------------------------------
> Daniel Lopez Janariz ([EMAIL PROTECTED])
> Web Services
> Computer Center
> Balearic Islands University
> -------------------------------------------
>
>
> Andrew S Tomlinson wrote:
> >
> > The first concrete example of mapping action "status/result" to
> destination
> > was given by Daniel to my recollection. It was part of his
> webleaf project.
> > There was mention also of a "state-machine" approach.
> > I prefer the "state-machine" approach for my specific application.
> > I deal with leasing systems and there is a re-entrant workflow
> that needs to
> > be modeled.
> > I assign a lease a code for each major step in the workflow ( "customer
> > details received", "credit approved", "documents sent" and so on).
> > Each step has a next logical requirement so I like to push the
> lease reps
> > onto the most appropriate screen when they load a deal. In
> other words if
> > the lease is waiting for documents to be produced the "Produce
> documents"
> > screen should be displayed if that lease is selected from the
> work queue.
> > Anyway, without boring everyone with the tedium of leasing, the point is
> > that a mapping of "status" to UI page intersects nicely with the Model 2
> > stuff espoused by the group on this list that make it worth
> subscribing to
> > (they know who they are..and thanks to them all for their insight).
> >
>
> ==================================================================
> =========
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
