Bernd Bohmann wrote:
Sean Schofield schrieb:
Yes, we have too much of this with Tobago and I think the results
speak for themselves. We rushed it in and now nobody knows what to do
with it besides the Tobago guys. We will resolve that issue
eventually (and again - the Tobgao stuff is good stuff.)
I'm very proud that you like the tobago components.
From a technical point it is not an easy step to integrate the tobago
components in tomahawk. Many gray cells are needed to solve the
layouting stuff, if non tobago components and tobago components must
coexist in one page. I don't expect this in a first step.
But we can talk about sharing code and concepts.
Some simple Examples:
We should not have 2 TabChangeListener, TabChangeEvent, UITabGroup... (I
expect adf faces have the same classes then 3) (By the way, I have
already changed the signature from the TabChangeEvent stuff to the
myfaces signatue. Now we can use it from a shared artifact of myfaces
easily)
Or 3 TreeModels.. and many other duplicate code
I expect we can share much code across the myfaces universe.
One other example:
Adam and I talked with Martin about partial Validation and subforms.
Tobago and ADF have a very similar solution. We should share it under
the myfaces umbrella :-)
An other area would be the javascript stuff
Volker has already asked for it.
I understand the incubator for solving ip issues and ensure the apache
way. The incubator is not for solving technical problems. The technical
problems should solved by the community.
You have already send a proposal for switching to maven2 and a
share/core/util package. So the things are under way that we can share
code and concepts. If you understand the layouting and the themes of
tobago you should very familiar which tobago. It is only a different
Renderkit :-).
I'm very familiar with the myfaces stuff execept the javascript, but
this applies for tobago, too.
I'm looking forward to see tobago integrated into the myfaces family.
And I'm looking forward to see adf faces under the myfaces umbrella.
Well I think it is quite ok, just to concentrate on the
code sharing and later try to integrate this stuff, this seems like a
viable way to me.
The main problem I see with all this is more JSF related and less
myfaces related. We have this critical conflict point view handlers
which cannot be combined in a decent way due to limitations
of the pattern and the handling of only being able to define one
per web application.
Now we have this situation that many libraries and component sets
use those to bypass some limitations of the JSF APIs
(Shale uses it for a simpler lifecycle handling and events
related to the requests to my knowledge, Tiles and Facelets use
them to kickstart their own rendering part for layouting, Tobago (I
really have to look at the code) probably for similar reasons)
None of them combinable out of the box.
Perfectly viable from a JSF standpoint but problematic from a user
standpoint, because the first thing which happens is that someone will
try to combine all this.
Well not solvable now, but it will be solvable. But in the end, this
problem has to be solved on the JSF spec level and ASAP.
But in the long run I am not sure if it is a good idea if component sets
themselves should define their own view handlers (I know partially the
reasons why Tobago and ADF did and they are viable)
At least not until the main problems with the view handlers are solved.
But this thing is more an issue which probably has to be resolved on the
JSF side and less on the code side.
(Get rid of the view handlers as defined by now and move the
functionality to a filter or chain pattern)
But having the possibility to share code and proven and well working
code to reduce code redundancy and code duplication is the first big +
we all will probably get out of this.
Btw. thanks guys for all the effort.
just my 2c to the whole situation
