-
1. Re: Wildcards for no-conversation-view-id
gavin.king Nov 3, 2006 5:42 PM (in response to iradix)It is possible to specify a global view id, using <pages no-conversation="..."> or org.jboss.seam.core.pages.noConversationViewId=...., but it is not possible to do it for a wildcard. You can request that in JIRA, if you like. But it won't be a high priority unless you supply a patch.
-
2. Re: Wildcards for no-conversation-view-id
iradix Nov 3, 2006 5:49 PM (in response to iradix)I'd imagine I could put that patch together int he next couple of days. Would you accept it if I worked in a way to specify an ordering of page actions as well? My initial thought is to fire them in the order by which they are specified in the XML document although that might mess with existing behavior a bit too much.
-
3. Re: Wildcards for no-conversation-view-id
gavin.king Nov 3, 2006 6:56 PM (in response to iradix)Currently there is a well-defined ordering with says "general before specific". ie. /x* called before /xxxx*. I don't want that to change.
-
4. Re: Wildcards for no-conversation-view-id
gavin.king Nov 3, 2006 6:57 PM (in response to iradix)If you do this, please take a look at this one at the same time:
http://jira.jboss.com/jira/browse/JBSEAM-397 -
5. Re: Wildcards for no-conversation-view-id
iradix Nov 6, 2006 11:16 AM (in response to iradix)No problem. I'll try to play around with that next week. As far as the ordering of page actions is concerned, I can see where you are coming from. Most of the generic page actions I've set up have been for things like checking permissions and I'd definitely want them to fire first. But what about the case where a page action starts a conversation and the rest of the pages within the group are conversational? You could move the conversational pages into their own folder or you could write an action that either starts the conversation or checks for it depending on the view id, but those both seem like hacks don't they? It seems like their should be a better way.
-
6. Re: Wildcards for no-conversation-view-id
iradix Nov 9, 2006 1:48 PM (in response to iradix)I've got an idea for revamping pages.xml. What if Page objects had a parent child relationship with each other, less specific matches parenting more specific children. For attributes that can only have a single value (no-conversation-id for instance) if the value isn't defined directly on the child, it will call through to it's parent until a value is found. For multiple values, like Page Parameters, the collections for each page in the hierarchy are combined, least specific first.
Actions would be treated like page parameters, and if I make this change I'd actually like add a nested element as well so that more than one action can be defined per page. I think this will be very useful for generic validations.
I also think an inheritFromParent flag would be useful in situations like the one I outlined above. If you want to explicitly define the ordering of your page actions, you could just set it to true and redifine within the specific page.
What do you think? -
7. Re: Wildcards for no-conversation-view-id
gavin.king Nov 10, 2006 11:20 AM (in response to iradix)This sounds like a very reasonable design to me. Probably better than the current one.
-
8. Re: Wildcards for no-conversation-view-id
iradix Nov 17, 2006 12:37 PM (in response to iradix)Ok, I'm working on this now. A few questions though:
I've got the latest CVS changes as of last night. Anything else I should know about changes to the Pages component that you are working on locally or had in mind?
What is the process for submitting patches? -
9. Re: Wildcards for no-conversation-view-id
gavin.king Nov 17, 2006 4:33 PM (in response to iradix)Nope, things are pretty-much locked down for the release now.
Process is create a diff and attach it to the JIRA issue. -
10. Re: Wildcards for no-conversation-view-id
iradix Nov 17, 2006 4:54 PM (in response to iradix)Ah, so there's no chance of getting a patch included before the release?
I've got another question after looking the code over more thoroughly. Is there any reason to continue firing actions after the first non-null outcome? It seems to me like a non-null outcome signals an immediate transition to a different page and actions further down the line should be ignored. As an example, if my /orders/* viewId defines a #{shopperOnly} action, if that returns a non-null result I want to go immediately to the login page. If not I may include other error messages down the line that won't make sense when the login page is arrived at. -
11. Re: Wildcards for no-conversation-view-id
gavin.king Nov 17, 2006 4:59 PM (in response to iradix)Ah, so there's no chance of getting a patch included before the release?
Proabably not, no. -
12. Re: Wildcards for no-conversation-view-id
iradix Nov 17, 2006 6:32 PM (in response to iradix)Ok, well it's just about done anyway. Changes I've made are:
You can now specify page parameters, no conversation view ids, timeouts, and resource bundles in wildcards. Page Parameters from all matches are combined while the others will fall back to the value defined on the most specific match.
Multiple actions can now be defined through<action>#{actions.action}</action>
elements nested within page elements. I also made it so that actions stop firing on the first non-null return. Gavin, if you disagree with this let me know, but it makes sense to me.
Added a conversational attribute to the page element that acts like the corresponding annotation.
I'm going to finish up testing and cleaning up the code, then probably submit a patch on Monday. If anyone has any requests while I'm at it, please let me know now. -
13. Re: Wildcards for no-conversation-view-id
gavin.king Nov 17, 2006 7:11 PM (in response to iradix)Great!
I also made it so that actions stop firing on the first non-null return. Gavin, if you disagree with this let me know, but it makes sense to me.
I think I disagree, but perhaps I can kinda see where you are coming from.... -
14. Re: Wildcards for no-conversation-view-id
iradix Nov 18, 2006 1:03 PM (in response to iradix)I think I disagree, but perhaps I can kinda see where you are coming from....
Maybe if you can give me a use case where an action should still fire even though an earlier action requested a view change we can come up with a compromise. All the actions I've used have been validations of some sort and as soon as they fail, I'd want to add an error message and redirect.