This week's book giveaway is in the HTML Pages with CSS and JavaScript forum.
We're giving away four copies of React Cookbook: Recipes for Mastering the React Framework and have David Griffiths & Dawn Griffiths on-line!
See this thread for details.
Win a copy of React Cookbook: Recipes for Mastering the React Framework this week in the HTML Pages with CSS and JavaScript forum!

Donald Jackson

Greenhorn
+ Follow
since Mar 09, 2009
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Donald Jackson

It depends on what phase of the application lifecycle the method in question is being called in. The commented out code simply sends control directly to the Render Response phase, skipping any of the other potential phases that may be between where the flow of control presently is and it's inevitable destination.

Think: Restore View -> Apply Request Values -> Process Validations -> Update Model -> Invoke Application -> Render Response

It depends a great deal on what the code leading up to the commented out lines was doing.

Mark
11 years ago
JSF
"One thing people tend to forget is that JSF wasn't designed just to manage views on web pages in HTML. That's why they split the renderers off from the core tag stuff."

Exactly. That's pretty much why I've had so much interest in the composition of components and the painful details about how they go together and what properties maps they're accessing and what not. I've been puzzling over the usefulness of having visual components that would work on a number of different platforms, say, where ever you could host a JVM and 2 inch LCD screen, ease of development on mobile or specialty devices with the ability to interface with the whole Java Enterprise infrastucture. Sounds like big fun to me.


Mark

11 years ago
JSF
Thank you Tim. My guess is that they wouldn't change the properties that getAttributes accesses although they may have changed the method of accessing them.

"... I wouldn't attempt to read and process all the inherited attributes in my own tag class, just the attributes I was overriding, if any. I'd let the superclass handle the rest of them."

Bingo. That's pretty much how I was figuring to approach it if I used the html components. BUT-> You suggest that I don't? You see, I wasn't sure about that part and I was wondering why people were subclassing UIComponents pretty much exclusively for non-composite components. So I gather that basically the UIComponent classes are designed for subclassing with component developers in mind and the Html classes are the html_basic renderkit implementation and I would be better served by leaving it alone. It's beginning to make sense to me now. I think I can safely move on to the next head scratcher now.


BTW... anybody got any idea how this Ajax stuff works....


Thanks,
Mark

11 years ago
JSF
"Actually, it sounds like you know too much for your own good!"

> Well, if that's true, you can blame it partly on Ed Burns and Chris Schalk since I'm pulling through their book: "JavaServer Faces 2.0: The Complete Reference", as well as digging through Mojarra source and various component librarys' source.

My objective is to be able to create a JSF non-composite component. Using the classes and resources that Mojarra provides along with my own selection of javascript, html, xml, css or whatever as my browser resources, I want to have the chops to be able to do it if I need or want to. Plus, whenever I don't particularly understand something I often start digging in until I get to the bottom of things and I'm satisfied that I do understand. Kinda like pulling a thread on a sweater, I can't stop until it's totally undone.

Now, back to PropertyKeys. See, I ran into this section in the book on pages 316 and 317 that discuss state management in custom components. The authors are basically saying that prior to jsf2.0 it was common practice to save and restore the state of a custom component using JavaBeans style property getter and setters to explicitly handle state within the component. Now, and I quote: "JSF2.0 introduces the StateHelper interface to make this sort of activity easier and less error prone." I don't know since my horn is pretty green, but to me it looks more complex than using getters and setters.

It goes on to say that the getter and setter method on UIInput now looks like this:

enum PropertyKeys {

/**
*<p>Flag indicating whether or not this component is valid.</p>
*/

valid

}

public boolean isValid() { return (Boolean) getStateHelper().eval(PropertyKeys.valid, true);}

public void setValid(boolean valid) { getStateHelper().put(PropertyKeys.valid, valid);}


Soooo... what do I do? Are these the same attibutes that are being handled by the getAttributes() call that all components that subclass UIComponent inherits? Or does getAttributes call into some other map hidden off yonder somewhere. The reason that I'm digging into this so tenaciously is because I keep trying to write these cool java web apps and everything I try to do becomes a rats nest and even the simplest of endeavors turns into a complex unworkable pile of disappointment. Yeah, I can follow these basic tutorials I find laying around and as long as I obey every detail and don't stray in any way, most of the time it works. HelloWorld can only take you so far though, right? The minute I try to do something the least bit interesting it hits the fan, and no one short of an expert can usually figure out why. Maybe I'm just unlucky?


Thanks again Tim,
Mark

11 years ago
JSF
Thanks Tim for your patience and interest in this. I do know that it is an implementation detail and that in general it's outside the bounds of what one needs to know in order to use and code to the JSF api. My problem is, I'm a visual thinker and I need to create a picture in my head in order to feel confident that I understand something.

So, are you basically saying that indeed, this is where the attributes live that are returned to you when you use getAttribute() in your code? This is where the options that are attached to tags such as <h:commandButton> reside and can be accessed by <h:commandButton id=xxx style=xxx etc..> or whatever the proper nomenclature is? Most importantly, if I'm using a component that translates to tag on a faclets page in my code and I call getAttributes() on it, these are the attributes that I have access to at that point? Also, when I call the StateHelper class in my code, is it these properties that are having their state saved and restored? This is what I'm stewing over. I need to be able to draw a line in my head from the UIComponent.getAttibutes() method and the getStateHelper() method to the place where these values are kept, otherwise I can not be confident that I understand what's actually going on when I call these methods.

Thank you so much for taking the time to try and help me.

Mark
11 years ago
JSF
http://java.sun.com/javaee/6/docs/api/javax/faces/component/html/package-summary.html

If you look at the bottom of the page there is a whole section of PropertyKeys. They are enums that are inner classes in the javax.faces.component.html package. I notice that component authors, most particularly the JSF component library PrimeFaces utilizes them as a properties map that is called through the StateHelper class. I'm trying to determine what their relationship is to the "big picture".

As an example, when you call ResponseWriter you're calling an abstract class without any implementation, so how does it work? Well, the actual implementation is in the "com.sun.faces.renderkit.html_basic" package in the class HtmlResponseWriter. Without that, we'd all be forced to implement ResponseWriter ourselves because ResponseWriter is just an empty class full of method declarations with no implementation... or we'd be limited to what it inherits from Writer.

So, following that convoluted logic, when you create a component that decends from say, UIPanel and you call getAttributes(), where are these attributes coming from? Are they coming from these mysterious PropertyKeys? What is the relationship between UIOutput.getAttibutes() and HtmlBody.getStateHelper().get(PropertyKeys.style)? Am I looking for a relationship that does not exist here?

Thanks,
Mark
11 years ago
JSF
Howdy JSFer's,

You know, I'm searching the web and the good ol' Big Moose Saloon for information on PropertyKeys in JavaServer Faces and I find the information to be rather sparse. Maybe it's because all the other JSFer's out there are so much brighter than I am and totally understand them, but truth be told, I'm struggling with them a little bit. Not only that, usage, examples and tutorials that take java enums into any kind of indepth discussion are hard to find as well. It's kinda like, "Well, yeah, java has enums now....so let's discuss generics. "

I'm looking at javax.faces.component.html and viewing a whole section that goes into each individual components' inner PropertyKeys class and I wonder why I can't find more info on it. The java doc says that enum elements of these property keys are CONSTANTS but the documentation doesn't capitalize them like it does most other constants. Also, if you're using the default html renderkit that comes with Mojarra and you call a components getAttributes() method, are you calling into these PropertyKeys elements of whatever base tag you're using? Does anyone want to share their insight on JSF component attributes and state, maybe have or know of a good online tutorial that will help me with this stuff.

I'm just having a hard time finding much information online about it. I mean, if you search this website for the term PropertyKeys, you don't even get one hit returned. I've even bought the "JavaServer Faces 2.0: The Complete Reference" book and it doesn't seem to be covered at all in there either. It's almost like they don't exist or don't matter, but I have sneaking suspicion that they do. Call it a hunch. Especially if you want to write a non-composite component and decorate the default renderkit. Maybe I'm mistaken. I usually am, but I sure could use any help that anyone would be willing to give me on understanding these things.

Thanks,
Mark
11 years ago
JSF
Thank you Tim. I guess my problem is as much a 'java' question as it is a 'faces' question. I'm familiar with using interfaces to type a variable or object to enable injecting a subclass into that variable or object. I've just been having a hard time figuring out how the implementation of the abstract ResponseWriter makes it's way into the custom component code that I see other folks writing.

I actually have downloaded the whole Mojarra source package and have been pulling through it. I did find the implementation of the abstract methods in "com\sun\faces\renderkit\html_basic" as HtmlResponseWriter. I've also been pulling through the PrimeFaces component library looking at how it was put together. I've been trying to get an indepth understanding of JavaServer Faces component libraries and I picked PrimeFaces as an object of study since it was lightest weight, least confusing looking library that I could find.... judging by just a short going over of different library's code bases.

He breaks all of his components down into 3 classes: 'Component' , 'ComponentRenderer, 'ComponentTag'. I see in all the 'ComponentRenderer' classes the import statement for ResponseWriter but I have been having trouble finding the direct connect between the abstract declaration and the actual implimentation of the methods belonging to ResponseWriter.

My best guess is that when extending UIComponent as an ancestor through UIPanel or UIOutput you are getting the implementation via the inherited RendererType since HTML_BASIC is it's default renderkit. All of his component classes simply decorate the default renderkit...which is what makes PrimeFaces light weight and less confusing.

I'm just rambling here, but if anything I've said is misguided please point it out to me.

Thanks,
Mark
11 years ago
JSF
Hi guys. I have a question about ResponseWriter. Where are the methods that perform the actual work located? I'm wanting to thoroughly understand how it works, and I see examples all the time of folks using ResponseWriter and using it's methods and what not, but it is an abstract class and all of the most useful methods are declared abstract as well. So where is the implementation and how are all these folks using it in their components when the methods are just empty abstract method declarations with no implementation?

I know that there must be some sort of implementation somewhere for stuff like: abstract void startElement ( ) and abstract void writeAttribute ( ). These methods do more than just transmit characters verbatum like the write method in the Writer class that it extends, but I find no implementation for them nor do I find anything in the using statements that would provide the implementation.

So please, can someone tell me where the code is that does the heavy lifting and how it comes about being called when someone uses javax.faces.context.ResponseWriter...otherwise I have to assume that it's all bogus and happens by "magic".

Thanks,
Mark

BTW...This is a real question, not an April Fools joke. Really, where is the class that implements the abstract methods in ResponseWriter?
11 years ago
JSF
Try using:

<h:inputText label="First Name" value="#{flash.firstname}"/>
<h:inputText label="Last Name" value="#{flash.surname}"/>

In your next page use:

<h: outputLabel value="#{flash.firstname} #{flash.surname}" />

Then you can access the value in your bean with:

Flash flash = FacesContext.getCurrentInstance().getExternalContext().getFlash();
setFirstname ((String) flash.get("firstname"));
setSurname ((String) flash.get("surname"));

You may have to use #{flash.keep.firstname} in your EL expression in your page tag though. I'm not sure. Using the "keep" function in the flash tag attribute allows the saved data to stay through another iteration of the view lifefcycle. It will take the data from one page view to the next only unless you use 'keep' to maintain it. You'll have to look into it, but I think this points you in the right direction to do what you want. Atleast this is one way.

Good luck,
Mark

11 years ago
JSF
I'm curious. Would 'JavaServer Faces 2.0: The Complete Reference' help me with getting an overall conceptual understanding of th JSF framework? I've looked over the table of contents at Amazon an it seems pretty thorough.
11 years ago
JSF
Well Bill, I don't think a little pollution would hurt matters. I'm probably over reaching my grasp here trying to understand JavaServer Faces <grok it's fullness>, but I've never learned anything unless I was over reaching. And I really would like to have this value expression [ValueExpression] business explained to me...I wasn't just using it as an example of my frustration with reading the JSF Specs. I'm sure that making it dense and legalistic is some kind of requirement for specifications as I have not seen one that wasn't written in that manner, but I can't say that I see it as being useful for anything other than making sure that only a precious few can actually understand it.
11 years ago
JSF
Here's an example of what I'm talking about:

From the JSF Spec section 3.1.4-

"Properties and attributes of standard concrete component classes may be value expression enabled. This means that,
rather than specifying a literal value as the parameter to a property or attribute setter, the caller instead associates a
ValueExpression (see Section 5.8.3 “ValueBinding”) whose getValue() method must be called (by the property
getter) to return the actual property value to be returned if no value has been set via the corresponding property setter. If
a property or attribute value has been set, that value must be returned by the property getter (shadowing any associated
value binding expression for this property)"

As you can see, this paragraph in the specification refers me to section 5.8.3 to help clarify what's going on here.
Well, section 5.8.3 illuminates us further by sending us on to section 7.9.3, which of course references back to section 7.1.10.

Now I don't mean to be dense and I apologize because I'm quite sure that I'm probably in over my head and shouldn't even be here,
but I know there has to be a simpler way to explain this.

Would some kind soul like to take a shot? I'd be most greatful.
11 years ago
JSF
I am reading it. Unfortunately, the more I read it, the dumber I get. I used to know what a value expression was until I read the JSF Specification, now I realize that I don't have a clue.
11 years ago
JSF
So basically, ICEfaces and Primefaces are component libraries that are built on top of and make calls into Mojarra. Mojarra is the base functionality of JavaServer Faces in the JEE6 libraries? Ok, that does make sense...it's what I suspected. I guess one of the issues that seems to confuse me while trying to figure out JSF is if you pull through the code files of ICEfaces and then pull through Primefaces the two libraries look so different it's hard to imagine that they do the same things and are calling into the same base libraries.

So leaves me with pulling through Mojarra piece by piece and saying "the foot-bone's connected to the ankle-bone" if you get my drift. The page markup calls into the servlet, that updates the doodads that locate the ELresolver that decodes the artifact that calls the backing bean that hydrates the entities...etc. Yes, I know, probably more convoluted and simplistic than the way you're used to thinking about programming, but unfortunately, that's how my mind works. I know there isn't always a linear one to one relationship between cause and effect but my thick browed habits are such that I always look for it.

I guess I'll just keep digging until I can draw the picture on my cave wall.
11 years ago
JSF