-
1. Re: Inject EL Results
denis-karpov Jul 20, 2006 6:14 AM (in response to mschmidke)You are digging in the wrong direction. Try to design your application in different way. You are trying to couple presentation and business. I assure you that you do not really need this.
-
2. Re: Inject EL Results
mschmidke Jul 20, 2006 6:55 AM (in response to mschmidke)Maybe wrong direction ... but the last idea I had.
Mixing business and presentation is bad, agreed. But even in Facelets there should be a possibility to write Java code to compute output text.
And in this case, this Java code needs two parameters, no way around. So there's no possibility to write a simple getter to be accessed from EL.
I also tried user defined EL functions. I spent half a day on it, but everything I do is completely ignored. JSTL functions - no problem. User defined functions - no way. Don't know.
So what is the right way to call a Java function and give it the parameters which are available in the component? -
3. Re: Inject EL Results
pmuir Jul 20, 2006 7:12 AM (in response to mschmidke)You could preprocess the output [1]. User defined functions (as you mention) are another option. If you have problems with them probably best to post on the facelets user mailing list (they do work as described in the manual).
[1] http://www.jboss.com/index.html?module=bb&op=viewtopic&t=86324 -
4. Re: Inject EL Results
gavin.king Jul 20, 2006 1:41 PM (in response to mschmidke)So I suppose that there is some kind of local variable storage in Facelets, which is not accessible from Seam.
Yes, ofcourse. This is a definite Good Thing. -
5. Re: Inject EL Results
mschmidke Jul 20, 2006 4:24 PM (in response to mschmidke)
Yes, ofcourse. This is a definite Good Thing.
Sorry for my stupidity, but I don't understand. The backing bean is part of the view, in this case, and I do not understand why it is not a good idea when the Java part of the view has the same knowledge as the xhtml part of it. -
6. Re: Inject EL Results
denis-karpov Jul 21, 2006 4:02 AM (in response to mschmidke)The backing bean is part of the view
No it is not. View connected to the beans by binding expressions. View does not hold references to the beans. In render time, when it is needed to put value in html output it just evaluates binding expression. And then in post time, it evaluates binding expression in another direction to put posted value back to the bean property. There is also method binding for the buttons and links, but it works by the same principles.
Facelets do the great thing. It gives a lot of template capabilities, and it get rid of JSP heritage. -
7. Re: Inject EL Results
cptnkirk Jul 21, 2006 4:17 AM (in response to mschmidke)While Seam may not have visibility into facelet's internal variable passing mechanism, isn't this information already present in a JSF or Seam context? How are you passing data as a parameter that didn't originate from somewhere Seam does have access?
-
8. Re: Inject EL Results
mschmidke Jul 21, 2006 4:50 AM (in response to mschmidke)"CptnKirk" wrote:
How are you passing data as a parameter that didn't originate from somewhere Seam does have access?
Yes ... of course. The data originates from somewhere else in Seam. But since I'm writing a component with reusability in mind, I don't want to worry about the variable name in the caller's scope.
Same as calling methods in plain Java. Inside the method, I don't (want to) know the variable name of the method caller.String name; print (name); public void print(String s) { ... at this place I don't want to access "name". This is something I did in my BASIC years. }
-
9. Re: Inject EL Results
cptnkirk Jul 21, 2006 11:09 AM (in response to mschmidke)If you want to pass parameters directly via EL I think your only option is to write an EL Function. Everything else in JSF is based on method binding EL which is a simple lookup. Method bindings depend on the bean having all the requisite state prior to invocation.
You could write a custom JSF component that takes in JSF params and communicates directly with your Seam component in Java land.
Or you can have a type specific context aware Seam component. UserManager.printUser(), that knows where to look up the user entity within Seam. This way JSF can take #{user} as a param and your Seam component can use a well known location to function properly.