I don't know If this is the right place to ask this question.
How do I make some non technical person to understand "Facelets as View technology"?
I try it.
If you use JSF as presentation layer you can use the advantages of input validation for forms, have a direct data binding to one or more ManagedBeans also known as PoJos with annotation #ManagedBean or #Model/#Named...
JSF components also support the usage of Ajax, so you can update tableviews asynchronous after adding new entries for example.
summarizing in my opinion it is easier to built a modern feeling site by using JSF, there are many different implementations e.g. primefaces, richfaces, etc. so you have the choice which framework you'll use.
Hope this helps, maybe the community can add more.
Patrick
Related
Jakarta Faces 4.0 introduced a new #ClientWindowScoped annotation. However, searching the specification and implementations, I haven't found any example of its practical use in applications.
Maybe it's not only the case to annotate a bean with this annotation, but also to manipulate the jfwid request parameter through some provided API. If that's the case, can anyone provide a simple example of how it can be used or point to an article that does?
Hybris tell us that Converters should use populators and not vice versa because can be critical for performance considerations.
But when I am digging in hybris code you can see populators like DefaultAbstractOrderEntryPopulator, ProductFeatureListPopulator which
are wiring converters.And I have also find Populators using other populators such as ProductPopulator.
I read the following links but I cannot find anything about using a converter inside a populator or populator inside of populators:
Wiki Hybris - Converters and Populators
Wiki Hybris - DTOS best practice
Wiki Hybris 6
so, can we use converters inside populator like Hybris does? and populators inside populators?
I would like to give my point of view to answer this question. One common mistake when working with converters and populators is to confuse them.
Converters creates a DTO and populators filling the DTO.
We have to be very careful when we are going to use a converter inside of a populator and to be completely sure that
we need to do that.
If we have a long chain of populators using converters we can have a performance risk. For instance
C1->P1->C2->P2->C3->P3....
I think the best practise to follow is:
1) Be aware of the converters are already done, and ckeck if we have to add our populator to an existing Converter
(for example using the modifyPopulatorList)
2) If our DTO has another dependency with other DTO
We should ask ourselves if that dependency it is really necessary.I will decide this according to if that second DTO is used in many places
or not.Because if you are the only one who use it maybe you can merge the properties in only one DTO and avoid to have two different converters.
3) Other possibility It is to use differents converter in parallel as we can see in
WIKI HYBRIS - Facades and DTOs
To sum up, the design of our converters and populators is our responsability, and we have to get the best design posible of them to avoid
performance problems.
Basically the way to do it is: never write a concrete converter class and never call a populator directly.
But this is how the product is built for extensibility and frankly you can do whatever you like.
I've been reading about the conversation scope in Java EE 6 (and therefore CDI 1.0), and how it can isolate data from different tabs in a browser, and preserve data across many requests of a particular workflow of pages. I've no issues there.
In my reading, I've read that many of its ideas came from Seam. Often I see caveats such as 'but CDI's conversationscope does not do "nested" conversations'. I'm not sure what exactly a "nested" conversation is?
I've read this good link also http://www.andygibson.net/blog/article/understanding-nested-conversations/
but I think I'm missing something fundamental.. I'm just not fully getting what a "nested" conversation is in this context. Can anyone help dumb it down for me?
From the Seam 2 documentation:
A nested conversation has its own conversation context, but can read values from the outer conversation's context. The outer conversation's context is read-only within a nested conversation, but because objects are obtained by reference, changes to the objects themselves will be reflected in the outer context.
So with nested conversations you have the chance to split a given parent conversation into several child conversations, each with both their context and access to the parent's context.
Although CDI was heavily influenced by Seam, it is so to say only a common denominator of several influences, so it does not contain everything which Seam had. The idea was, that by creating CDI extensions, such as Seam 3 was about and what now should be done by Apache Deltaspike, more features commonly used could be provided above the CDI standard.
Unfortunately, I am very disappointed with what Deltaspike provides and allthough JavaEE 6 and thus CDI is so long in existence, there is still a gap between what I was used to with my Seam 2 projects. I mean honestly, just have a look at the Deltaspike Homepage which starts with the words "Some logos ideas" which in turn ends my confidence in it...
NOTE: I have a related question here (http://stackoverflow.com/questions/6915055/are-jsf-views-shared-between-users) but that deals with a few other issues, so I am creating this one to focus on a more specific area.
I am using RichFaces (and in the last few weeks, have gotten a better feel for its implementation, object distribution, memory footprint, and things of that nature) along with JSR-168 Portlets, and am running into scalability issues. Given that a majority of my pages (aka, views) are user-agnostic (they are read-only, and generic to the user community for the most part), I want to force the RichFaces Framework to create a single view (# of logical views and sessions is set to 1 in web.xml) that is shared across the sessions.
In other words, I don't want any more than 1 view per session (easily, done by the config params mentioned above in web.xml) but more importantly, I don't want more than 1 view (of the same underlying view definition) even across sessions.
Now, what would it take to accomplish this?
I figured this one out. I extended the JBoss Portlet Bridge and JSF StateHolder classes (amongst other things) and have a custom implementation that lets me share the JSF views across user sessions (again, these views are read-only and generic to the user community). The ones that are session-specific, I just let those resort to the default behavior. This has helped cut the JSF contribution to the overall session size (in terms of memory) by about half.
When a form is submitted, some properties pass validation and some don't. If any of the properties fail validation, the model is not updated. I was wondering, is it possible to change this default behavior and have the properties that pass validation (and only them) updated with their new values in the model?
It's not directly possible without providing your own LifeCycle implementation. This behaviour is namely explicitly definied in the JSF specification. Doing things differently would mean that you void the JSF specification.
What's the rationale behind this question? If you elaborate that, you may get easier workable solutions.
Update: the requirement is sound. You want to autosave forms. You may find this IBM article useful then.