1 2 Previous Next 19 Replies Latest reply on Nov 20, 2006 4:45 PM by iradix

    Wildcards for no-conversation-view-id

    iradix

      After looking at the source I'm thinking that using a wildcard to specify a no-conversation-view-id for a group of pages isn't currently possible. Is that right? Shouldn't it be? Generally I have several groups of pages that each constitute an individual conversation, but they are not really complex enough to merit pageflows in my opinion. They all look very much the same: the conversation is started by an action within pages.xml before the first page is displayed, and the rest of the pages/actions are conversation and protected either through a wildcard page-action or the @Conversational annotation. Otherwise, there is nothing to differentiate those internal pages from each other so it would be nice to just say:

      <page view-id="/group-starter" action="#{conversation.begin}"/>
      
      <page view-id="/group/*" no-conversation-view-id="/group-starter" action="#{conversationUtils.conversational}"/>


      rather than creating a page element for every individual page within the conversation.

      This actually feeds into some other issues like the fact that wildcard actions occur first, which means that I cannot easily group all of the pages together (if my example /group-starter page was instead /group/group-starter, the #{conversationUtils.conversational} action would fire first never allowing the #{conversation.begin} action to occur) but maybe that's best left for another post.

        • 1. Re: Wildcards for no-conversation-view-id
          gavin.king

          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

            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

              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

                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

                  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

                    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

                      This sounds like a very reasonable design to me. Probably better than the current one.

                      • 8. Re: Wildcards for no-conversation-view-id
                        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

                          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

                            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

                               

                              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

                                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

                                  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

                                     

                                    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.

                                    1 2 Previous Next