On 5/27/05, Werner Punz <[EMAIL PROTECTED]> wrote: > Craig McClanahan wrote: > > On 5/27/05, Werner Punz <[EMAIL PROTECTED]> wrote: > > > >>Sean Schofield wrote: > >> > >>>FYI there is some really cool stuff going on with dialogs in Struts > >>>Shale right now. Its all built on top of JSF and there are some > >>>"nightly" examples you can download from Craig's website. > >>> > >>>Of course you can accomplish this without Shale (see Martin's > >>>suggestions) but Shale provides a nice "standard" way of solving the > >>>"dialog problem." > >>> > >> > >>Well I checked shale yesterday, it looks really nice, but I have one > >>gripe with it, Callahan introduces yet another xml syntax for the page > >>flow, which really is totally redundant because the pageflow already is > >>covered in the faces-config description. > >> > >>The better approach would be to use some kind of dialog marker tag, > >>which marks the dialog boundaries, and let JSF keep the page flow. > >>JSF has way too many artefacts scattered around the filesystem already > >>(a huge design mistake, it inherited from Struts), we dont neet yet > >>another artefact, and even one, which ist totally redundant. > >> > >> > > > > > > Not really redundant, in at least a couple of areas: > > > > * JSF 1.x doesn't have any notion of mapping to an action state; > > it only knows about view states. > > > Correct me if I am wrong, but is an action state not just another > redirect in a page centric view... so I do not see any point except > mapping things to the UML paradigm.
No, as currently implemented an action state is a method call (configured using a method binding expression) to some public method on a bean -- typically a managed bean so you get the create-on-demand and dependency injection features -- that returns a String outcome. That outcome can then be used to select a transition to some other state. Note that you can chain action states together if you want, as well, to support fine grained reusable behaviors. The container has no notion that any of this is going on -- it's not implemented with RequestDispatcher.forward() or with redirects. JSF only knows how to navigate to views. A Shale ViewController provides the equivalent of a setup action for you (prerender), but that *requires* you to put the corresponding logic in the same bean as the processing logic. Some folks prefer a design pattern that allows you to reuse setup actions across different views (i.e. call the same action method for the several places where you need to look up all the orders for a particular customer). Dialog lets you do that. > > > * JSF 1.x maps outcomes to new (view) states globally per application, > > which means you cannot reuse the same view in more than one dialog. > > > point taken in this regard... this is a huge hole in the specs, which I > also hate. Remember that it was a 1.0 spec, whose primary goal was getting the component APIs right. This is the sort of functionality that can be added later, so consider dialogs some real life research into what kinds of facilities like this should later be standardized. > > > * Besides the "global" restriction, JSF 1.x doesn't have any support for > > a "dialog scope" (longer than a request, shorter than a session) -- you > > have to do all that kind of state management by yourself. > > > that is resolvable with less artefacts by the introduction > of a scope or dialog tag, which does the handling in a for the end user > easier way. What kind of tag? I guess you're talking about a JSP custom tag of some sort? In the long run, I think support for something like dialog scope really belongs at the servlet API level so that all the web tier technologies could benefit from it -- but that's for the future, and this is now. > > > None of these "limitations" of JSF 1.x should really be that > > surprising; the focus was on creating a view tier component API. > > Shale, on the other hand, is about creating a controller tier API that > > is synergistic with JSF's basic controller capabilities, rather than > > treating it as simply a custom tag library (like the Struts HTML > > tags). > > > > > If the ideas in Shale's dialog management end up in JSF 2.0 (which > > doesn't seem unlikely to *me*, but that will be up to the JSF 2.0 > > expert group), then great. In the mean time, the ability to script a > > dialog, with both action and view states, and to build a tool to > > assist a user in graphically assembling such a dialog, then reusing it > > as a black box, is pretty helpful. > > > > Yes... but the main problem is, that it again is way to complicated > to use by introducing another set of artefacts in an already artefact > bloated system. > Sorry ... I still don't understand how your contention that the standard JSF configuration mechanism provides "everything you need" for dialog management is supported. And, by the way, those artifacts are part of what makes building tools to support developers much easier. Go grab a copy of Creator and play with the page navigation support (adding a navigation rule is done by dragging a mouse from one page to another) -- you can edit the XML if you really want to, but it's much nicer not to have to. The configuration of dialogs is very much amenable to the same kind of support. > Shale started as a project which should make things easier for the user > (the main problem to my knowlege most people had with both Struts and > JSF was the artefact management, which JSF is better than struts but > still far from being easy to handle) > > To keep the number of artefacts low, I think the correct approach would > be to try not to introduce yet another xml type and to try to cover as > much as possible with tags and not with another layer of frameworks, > which you force upon the user to use. (there are way to many framework > hooks in JSF already, which sometimes are hard to grasp. The main two > examples which come to my mind are the component model framework and the > Datamodel, which both could have been way easier ) > > > Minimizing configuration artifacts is not the primary measure of ease of use for developers. Indeed, the fact that Struts *required* a config file (over and above web.xml) was one of the most important factors in its success. Craig > > Craig
