Dynaview with cdi expression and method

Splash Forums Rewrite Users Dynaview with cdi expression and method

This topic contains 9 replies, has 3 voices, and was last updated by  marnix 2 years, 11 months ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #24579

    marnix
    Participant

    Hello,

    I’m switching from PrettyFaces to PrettyRewrite. Most urls work, except my urls which use a dynaview. This is my pretty faces configuration (part):

      <url-mapping id="content_by_url">
        <pattern value="/#{/\\D{1}[\\w\\-]{19}.*/url : cmsBB.url}" />
        <view-id value="#{cmsBB.getViewIdForUrl}" />
      </url-mapping>
    

    I read all examples and many topics from this forum.
    I found this construction from topic http://ocpsoft.org/support/topic/jsf-actions-using-rewrite/:

    
     return ConfigurationBuilder
                   .begin()
                   .addRule()
                   .when(Path.matches("/name/{name}"))
                   .perform(PhaseAction.retrieveFrom(El.retrievalMethod("#{expressionLanguageBean.action}"))
                            .after(PhaseId.RESTORE_VIEW)
                            .and(Forward.to("/expression-language.xhtml")))
                   .where("name").bindsTo(PhaseBinding.to(El.property("#{expressionLanguageBean.name}"))
                            .after(PhaseId.RESTORE_VIEW));
    

    but my forward is dynamic and retrieved from my backingbean.
    What lines must be added to make it work?

    Btw, as a test, I included rewrite-config-prettyfaces-2.0.5.jar and enabled my old pretty-config.xml and then it works, but I try to make it work without pretty-faces.xml and with my own RewriteConfigurationProvider, because it’s more powerful.

    #24588

    Hmmm… that’s a good question. I think you’ll need to add a second PhaseAction that gets FacesContext.currentInstance() and does the internal JSF navigation. We haven’t yet tried to re-implement dynaview in Rewrite, but if that works, maybe it’s enough to add a composite rule to take care of the dirty-work :).

    #24610

    @lincoln: Isn’t this just a matter of implementing a custom Operation which calculates the URL to forward to dynamically? This isn’t exactly what Dynaview does, but it’s close. 🙂

    #24629

    Well yes and no. Dynaview works this way because it needs an internal view to handle the request, then calculate the next view within the JSF lifecycle, so yes, technically that’s right.

    #24640

    So if you don’t need an active JSF lifecycle to calculate the real view ID, you could also go with a custom operation that does a forward, right?

    #24641

    marnix
    Participant

    I need an active JSF lifecycle because the method getViewIdForUrl uses the url to fetch an article entity from the database. The article entity contains the jsf view for the article.

    The prettyfaces compatability module (rewrite-config-prettyfaces-2.0.5.jar) can read the dynaview configuration and it works. I don’t know if this module uses pretty rewrite or that it contains the “old” pretty faces code to create the required functionality. It’s a large jar with a lot of classes.

    This was my last try to let it work (but it doesn’t work):

    
        ConfigurationRuleBuilderCustom rule = config.addRule();
        Condition condition = Direction.isInbound().and(Path.matches("/{url}"));
    
        rule.when(condition);
    //    ConfigurationRuleBuilderPerform perform = rule.perform(operation);
        El getView = El.retrievalMethod("#{cmsBB.getViewIdForUrl}");
        PhaseAction phaseAction = PhaseAction.retrieveFrom(getView);
    
        Operation forwardOperation = new HttpOperation() {
          public void performHttp(HttpServletRewrite event, EvaluationContext context) {
            String to;
            to = cmsBB.getDynaView();
            Forward.to(to).perform(event, context);
          }
        };
        phaseAction.after(PhaseId.RESTORE_VIEW).and(forwardOperation);
    
        ConfigurationRuleBuilderPerform perform = rule.perform(phaseAction);
        ConfigurationRuleParameterWhere where = perform.where("url");
        where.matches("\\D{1}[\\w\\-]{19}.*");
        PhaseBinding phaseBinding = PhaseBinding.to(El.property("cmsBB.url"));
        phaseBinding.after(PhaseId.RESTORE_VIEW);
        Binding binding = phaseBinding;
        where.bindsTo(binding);
    

    To better understand all classes I created local variables for a lot of objects, but when everything works I will use the short syntax with method chaining.

    #24645

    The prettyfaces-config-rewrite uses old prettyfaces code to implement DynaView, mixed with a small amount of rewrite code simply to do the integration.

    https://github.com/ocpsoft/rewrite/blob/master/config-prettyfaces/src/main/java/com/ocpsoft/pretty/faces/config/dynaview/DynaviewEngine.java

    #24650

    marnix
    Participant

    Ok, the challenge is to make the dynaview functionality with only pretty rewrite code and without old pretty faces code. It should be possible, right?

    #24683

    Yes, it should definitely be possible. In fact- it should be pretty easy if you have a handle on the Rewrite architecture and don’t mind a little debugging to see how things work inside 🙂

    #24781

    marnix
    Participant

    Unfortunately I don’t have enough time to dig into the source code and find out how things work inside. I will rollback my code, use rewrite-config-prettyfaces and wait until I know how to write the “magic” 😉 pretty rewrite lines for my use case 🙁

    Many thanks for all answers. If someone finds out how to get the dynaview functionality I need, I’m still interested.

    Regards, Marnix

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.

Comments are closed.