@Parameter and null-values

Splash Forums Rewrite Users @Parameter and null-values

This topic contains 21 replies, has 3 voices, and was last updated by  reinhard hobler 2 years, 7 months ago.

Viewing 15 posts - 1 through 15 (of 22 total)
  • Author
    Posts
  • #25385

    reinhard hobler
    Participant

    This morning I continued my evaluation on rewrite.

    Consider the following scenario:
    We have a bundle of web-frontends that are more or less designed as RIA-applications. Let’s say we have a main Customer Page where we show information related to customers.

    Initially, the customer.xhtml page is rendered without a customer loaded. On the page the user then can search and open a certain customer (via a modal search-dialog). The customer is then loaded from database and the (initally empty) fields on the page are filled.

    I now would like have this two ‘states’ of the page considered in the related urls.

    With rewrite I kind of managed it to get

    
    host:port/customerapplication/customer
    

    for the ’empty’ customer-page and

    
    host:port/customerapplication/customer/?customerId=4711
    

    when customer 4711 is loaded.

    It would be much nicer if the URL here would be

    
    host:port/customerapplication/customer/4711   
    

    but if I change

    
    @Join(path = "/customer", to = "/jsf/customer.xhtml")
    

    to

    
    @Join(path = "/customer/{customerId}", to = "/jsf/customer.xhtml")
    

    I get a 404 when targeting host:port/customerapplication/customer.

    I am now not sure whether this not possible at all or if I missed s.th. out.

    Please find attached both the jsf-page and the corresponding Backing-bean.

    Attachments:
    1. CustomerBean.java
    #25389

    reinhard hobler
    Participant

    added customer.xhtml

    Attachments:
    1. customer1.xhtml
    #25391

    If you want host:port/customerapplication/customer to work, you need a rule for that 🙂 since host:port/customerapplication/customer/X has an extra required segment according to your join rule.

    You need both of these for what you want:

    @Join(path = "/customer", to = "/jsf/customer.xhtml")
    @Join(path = "/customer/{customerId}", to = "/jsf/customer.xhtml")

    I don’t believe we have an aggregate @Joins annotation, but you could use this one until the next release (I think we should add it.)

    import java.lang.annotation.Documented;
    import java.lang.annotation.ElementType;
    import java.lang.annotation.Inherited;
    import java.lang.annotation.Retention;
    import java.lang.annotation.RetentionPolicy;
    import java.lang.annotation.Target;
    
    import org.ocpsoft.rewrite.annotation.Join;
    
    @Inherited
    @Documented
    @Target(ElementType.TYPE)
    @Retention(RetentionPolicy.RUNTIME)
    public @interface Joins
    {
       Join[] value();
    }
    

    Then just do this on your class:

    @Joins({
      @Join(path = "/customer", to = "/jsf/customer.xhtml"),
      @Join(path = "/customer/{customerId}", to = "/jsf/customer.xhtml")
    })

    Let me know if this works for you. (Otherwise you’ll need two classes, one for each Join annotation.
    ~Lincoln

    #25392

    Created issue: https://github.com/ocpsoft/rewrite/issues/149 to track this functionality.

    #25401

    reinhard hobler
    Participant

    The solution with the aggregate @Joins annotation did not really work – I got a 404 for both variants. Here I will wait for the next release 🙂

    However, I got it working by using a Rewrite configuration class with rules for the two joins:

    import javax.servlet.ServletContext;
    
    import org.ocpsoft.rewrite.config.Configuration;
    import org.ocpsoft.rewrite.config.ConfigurationBuilder;
    import org.ocpsoft.rewrite.servlet.config.HttpConfigurationProvider;
    import org.ocpsoft.rewrite.servlet.config.rule.Join;
    
    public class RewriteConfig extends HttpConfigurationProvider {
    
    	@Override
    	public Configuration getConfiguration(ServletContext context) {
    		return ConfigurationBuilder.begin()
    				.addRule(Join.path("/customer/{customerId}").to("/faces/customer.xhtml"))
    				.addRule(Join.path("/customer").to("/faces/customer.xhtml"));
    	}
    
    	@Override
    	public int priority() {
    		// TODO Auto-generated method stub
    		return 10;
    	}
    
    }

    There are two points not so nice with that approach:

    First I can’t use navigation via your Navigate anymore (see CustomerBean.java) as then I get an IllegalArgumentException:

    Caused by: java.lang.IllegalArgumentException: Unable to find the resource path for: ...
    	at org.ocpsoft.rewrite.faces.navigate.Navigate.to(Navigate.java:84)

    So I had to change the method to s.th. like this:

    public String openCustomer() {
    		refreshCustomer();
    
    		return "/customer.xhtml?customerId=" + customerId + "&faces-redirect=true";
    
    	}

    Second point is that now the order of the rules in the rewrite configuration is crucial. If I put the rule with the parameter last then the above actionMethod openCustomer() leds to the following url: host:port/customerapplication/customer/?customerId=4711

    #25402

    Yeah I think I know why @Joins didn’t work, sorry about that.

    Navigation is just a truth of the design.

    But… the last part seems like it might be an improvement area for us. Do you think you could upload your app (or a small maven sample application) so that I could take a look at the code and the behavior?

    Thanks!

    #25403

    reinhard hobler
    Participant

    Please find attached the sample project and the app.

    Thanks for looking into the issue !

    #25417

    Hey Reinhard,

    sorry for the late reply. I’ve a comment regarding one of your latest posts. You wrote that you cannot use Navigate any more if you don’t use annotations for configuration. That’s not exactly true. Instead of passing the class you can also pass a string in. So something like this should work:

    public Navigate openCustomer() {
        refreshCustomer();
        return Navigate.to("/faces/customer.xhtml").with("customerId", customerId);
    }
    

    Not so nice like passing in the class but it is simple compared to string concatenation. 🙂

    Christian

    #25427

    reinhard hobler
    Participant

    Hi Christian,

    yes this is working too and it looks much nicer than concatenating the url.

    Thanks !

    Reinhard

    #25600

    reinhard hobler
    Participant

    Unfortunately, with the new Release of rewrite (2.0.9) my rule
    .addRule(Join.path("/customer/{customerId}").to("/faces/customer.xhtml")) does not work properly anymore.

    If I update the parameter customerId via the h:inputText on my xhtml-page and then call the action the url is rendered fine.

    But when I call a specific url like host:port/customerapplication/customer/X directly the X is not transferred to the parameter anymore.

    With 2.0.8 this was working fine 🙁

    #25604

    Hmm,

    This is very strange. I don’t know what we would have changed that would affect this. Could you provide the backing bean, xhtml page, and rewrite rule code? Or even better, could you provide a small sample application including just these things? I’d like to debug and see what is happening.

    Though maybe Christian has more immediate thoughts as to what might be going wrong here.

    Thanks!
    ~Lincoln

    #25608

    reinhard hobler
    Participant

    Hi Lincoln,

    You can reproduce that with the sample app provided in comment #25403:

    Thanks
    Reinhard

    #25609

    reinhard hobler
    Participant

    Hi Lincoln,

    You can reproduce that with the sample app provided in comment #25403:

    Thanks
    Reinhard

    #25610

    Okay, great! I’ll try it out as soon as I get a few spare minutes.

    #25614

    Hey Reinhard,

    thanks for providing the sample app. Which container do you deploy to? And could you please also post the exact steps to reproduce the issue? Thanks.

    Christian

Viewing 15 posts - 1 through 15 (of 22 total)

You must be logged in to reply to this topic.

Comments are closed.