Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

What tags of a xhtml view will be build as UIComponents in server side in JSF?  RSS feed

 
Jorge Martinez
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hy,

In order to create an xhtml view:

1. All jsf tags like datatable, form, etc.. will generate UIComponents in server side, right?
2. All non JSF tags will not generate UIComponents in server side, right?
3. If you want something in a view that will be the same across users and requests, I mean, It will not change like a label tag, it doestn make any sense to create it with a JSF tag in order to save memory in server side, right?

Thanks
 
Tim Holloway
Bartender
Posts: 18709
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're still trying to second-guess JSF internals. That's dangerous.

I have no idea what tags convert to UIComponents, but I'd guess that all of them do. Including straight HTML tags, META tags, Processing Instructions, text strings etc., etc. etc. Besides, the actual UIComponents only exist for a short period of time. The UIComponent tree is simply the working storage used to process the JSF lifecyle. It's re-constructed during the Restore View phase, updated and referenced as needed throughout the lifecycle, then discarded. In the interim, it can contain anything needed to facilitate the operation of the JSF Controllers. The precise contents of the UIComponent tree are likely to vary depending on what brand and version of JSF you are using.

I don't care what tags generate UIComponents. There's no point in warping your design to solve a problem that may not exist. It's a lot easier to diagnose and solve problems that occur in clean, simple code based on measurements of what the actual problem is (assuming you ever encounter one) than it is to do so when the code is twisted to solve a problem that never existed.

 
Jorge Martinez
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok,


Some doubts when you say "It's re-constructed during the Restore View phase, updated and referenced as needed throughout the lifecycle, then discarded" and "the actual UIComponents only exist for a short period of time".

- I thought the state of UIComponents like "conversors, validators, some render properties" were stored in user`s session because as this link says "http://stackoverflow.com/questions/7349174/why-does-jsf-save-component-tree-state", the UIComponents can be altered programatically so in order to keep their state it has be stored in session so when you say "UIComponents only exist for a short period of time" I dont understand it

Thanks
 
Tim Holloway
Bartender
Posts: 18709
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What you are referring to is the ViewState. It is what's used to rebuild the current state of the UIComponent tree in the Restore View phase and it is sufficient to rebuild the UIComponent tree, but it isn't itself a literal dump of the UIComponent tree.

You DEFINITELY shouldn't code based on internal details of ViewState. It was radically altered between JSF 1 and JSF 2 and any apps that you might have coded for JSF1 would have promptly ceased to function.

ViewState isn't "session" based in the sense of HttpSession (session objects). It's session-based in the sense of the abstract session between HTTP client and server. Depending on settings in web.xml, the ViewState may be stored in an undefined location within the webapp (NOT necessarily in the HttpSession object) OR it may be passed back and forth between client and server, having no fixed residence. Server-based ViewState is more secure and less network overhead, but client-based ViewState allows more scalability, since less server storage has to be dedicated per-client (session).
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!