What do you guys think of this idea?

[gavin.king]

http://jira.jboss.com/jira/browse/JBSEAM-510

WDYT? Would you use this in preference to pages.xml?

[alpheratz-jb]

I'd like to know your thoughts: what has driven you to propose this idea?

I'm not sure I would use this in preference...in addition, possibly.

I can see that it would make quick hacks easier and would be very useful for situations that only affect a single-page.

I can see some disadvantages: harder to 'grok' the flows in the app without looking at all the views; not so good for (postulated, future) tool support...the flow/actions of an app would be all over the place, rather than in one place (ok...a few places: faces-config/pages/jpbm config files...but these do gather flows up); harder to configure global aspects (ie using pages.xml to check for whether a user is logged in or not before allowing access to sensitive sections of a web app....it would not be as nice to have to guard every page individually). Seems to me that this is what drove the development/introduction of the front-controller idea in the first place?

ahhh...I seem to have heard all this in the Java Annotations vs. XML config files wars of yore.

Just my AU$0.02...

Cheers,

Alph.

[gavin.king]

Well, the thing is that in a large app you are going to need to split your pages.xml up anyway (which is why seam 1.1 lets you put stuff in myViewId.page.xml files as an alternative to META-INF/pages.xml). But then you get back to the same kind of thing that sucked with Java (code and metadata in two files). So, i wondered if the solution that worked well for Java could also work here. I mean ... the view template is _already_ XML, so why not stick some more XML in there...

It kinda goes back more to the oldschool style of JSP app where everything was driven by the page definition than the action-style web framework. Remember that JSF is naturally page-oriented, not action-oriented.

Anyway, its just an idea.

[rlhr]

In my opinion, I usually like to keep different things in different files.
In a large application, it is nice to be able to split a page.xml file so that each file groups related definitions. It can be also nice to have the flexibility to have these differents page.xml in various location as well.

I think putting xml definitions on a page would be manageable in a small app, I'm not convinced it would be better in a large app.

EJB3 got rid of redundancy of information. Before non only we had to write a metadata file for each ejb, but also the interfaces,... So for each ejb, we had to write a bunch of files. Annotation got rid of all the redundancy by generating automatically everything needed from one single source.
In this case, nothing is removed to be generated for us. It is more about where to put some info that needs to be written anyway.

So as I said, I believe in separating things unless putting them together really does improve a lot the development cycle.

This is just my opinion :)

[denis-karpov]

I think it is good idea to hold the meta information in the file with view.
Because there is no need in a separation. All information in page.xml now concerns a particular views.

It is matter of grouping by type or by subject. In this case I should prefer grouping by subject.

Yes, I usually also like to keep different things in different places, but let us be wise with this.

Denis Karpov

[bsmithjj]

I would like to try this technique out.

It seems to me that being able to invoke a component method from a page using this technique is more in the 'spirit' of Seam than pages.xml (which gives Seam a bit of a struts flavor - basically, in pages.xml, you're saying via an XML config file that an action (or component method) in your code is associated with a page or URI pattern).

This proposed technique may possibly make for more sophisticated templating strategies in pages that are built up using <ui:composition...> etc. from Facelets as well.

my 2 cents.

[iradix]

I really like it. I actually tried to do something like this with facelets before giving in and adopting pages.xml because I didn't have enough time and the facelets tags would fire at Restore View so they didn't integrate with conversations well. Pages.xml would still be useful for wildcard type actions, but if you are performing state validation on a particular page why go to a seperate file?

[chane]

Interesting.

I usually like to keep things together rather than spread out over many files. So I will probably give this a try if/when it appears.

However, I do like having a pages.xml for actions that relate to many pages. I also have entries in pages.xml that don't relate to a specific page but point to a method on an SLSB. I could probably put the definition in a page just to have it defined somewhere, but I would like it in pages.xml better.

Chris....

[iradix]

Just some observations on how this might be done. Figured this is a more appropriate place to have this discussion than within the JIRA issue. Parsing the XML from the view seems to have three drawbacks as far as I can see.

The first is that the page has to be XML, this doesn't affect me and I'd imagine most SEAM users are using Facelets as well, but still it would be nice if it worked with any faces view type.

The second is I agree with bsmithjj that it might be nice to nest these within templates. If you directly parse the XML it seems to me that you would have to either ignore definitions in templates or tie the parser to the view technology (Facelets) and parse all templates/includes as well.

The last is that if this ties in to the existing method in Pages of reading a Page definition and then caching it, these won't be reloadable without reloading the context which might confuse people since it is not how they are familiar with views working. Of course that could be worked around.

As an alternative what about making these actual UIComponents and then walking the Component tree in beforeRender if no page definition is found elsewhere?

[gavin.king]

If you want to write JSF components for that stuff, I guess it makes sense, just seemed like a real PIA to implement and maintain.

[iradix]

Yeah, I can see where you are coming from. I didn't mean that to come off as advocating components as the way to go, I just figured I'd throw it out there while the issue was being discussed. The real question in my mind becomes would people really want to include these in templates as somewhat of a replacement for wildcards. Then, I guess the next question is, is that a good idea :)

[gavin.king]

I don't really see it as a good idea, no :)

[bsheward]

I like the idea of having pages and flows separate.

We've been looking at using jPDL to define pageflows, hoping that this would allow us to control conversations and some logic outside the scope of any page, and allow less technical people to edit the flows using the JBoss IDE.

The things that stopped us was the inability to nest jPDL pageflows. I'd vote for nested jPDL pageflow functionality to be implemented first! :-)

[iradix]

It's not the page flows that would be defined within pages but the rules in the pages.xml file. Page Flows provide for stateful view transitions, pages.xml provides the ability to perform actions or change Seams behaviour based on view id.

[gavin.king]

It's not the page flows that would be defined within pages but the rules in the pages.xml file.

Right.

The things that stopped us was the inability to nest jPDL pageflows. I'd vote for nested jPDL pageflow functionality to be implemented first! :-)

This is possible as of CR1, but you *must* use a nested conversation. ie. begin the pageflow using @Begin(nested=true, pageflow="pfname"). Check the updated numberguess example.

What we don't have yet is "pageflow composition", which means the ability to compose pageflows by specifying that one pageflow includes another, without changing the code or conversation model. That capability is certainly higher on the priority list than the stuff we are discussing here. And note that Seam/Security is higher on the priority list than either of these.