You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Jan-Kees van Andel <ja...@gmail.com> on 2009/12/03 11:20:50 UTC
Trinidad and JSF 2.0
Hey,
I'm just asking this out of curiosity, so no offense intended. ;-)
I see a lot of JSF 2.0 related activity in Trinidad and I was
wondering, why not leverage the JSF 2.0 code in MyFaces Core?
Are there (legacy) reasons to keep the UIX classes and not replace
them (maybe partially) with their JSF 2.0 equivalents?
I can imagine that interoperability with other libraries increases
when Trinidad builds on (or extends) the JSF 2.0 API.
Regards,
Jan-Kees
Re: Trinidad and JSF 2.0
Posted by Gabrielle Crawford <ga...@oracle.com>.
Hi,
Andy is at a conference, I can try to talk to him about this next week.
Thanks,
Gabrielle
Martin Koci wrote:
> Hi,
>
> regarding component.getAttributes() vs. bean.getProperty() performance:
>
> do you have info under which circumstances is that difference
> noticeable? I do some profiling on two apps: the first one is
> trinidad12/jsf12 based and the second is JSF2 based. In both cases I
> have same view but JSF2 based application uses UIComponent and newly
> developed renderers instead trinidad. For example: CoreInputText ->
> NewInputText and SimpleInputTextRenderer -> NewSimpleInputTextRenderer.
> Algorithm in new renderers is the same as in trinidad but uses
> getAttributes() directly.
>
> I didn't notice a performance regression but maybe I look at wrong
> places. Obviously it must cost something especially during render
> response. Test is done for very complex view, loading is simulated as
> 100 concurrently working users - but YourKitProfiler shows very similar
> results for render response phase. Memory profiling I didn't do yet.
>
>
> Thanks,
>
> Martin Kočí
>
> Gabrielle Crawford píše v Čt 03. 12. 2009 v 09:29 -0800:
>
>> Hi,
>>
>> Our implementation of facesBean in 1.2 already supported
>> partialStateSaving, and for JSF 2 it's now a partialStateHolder
>> https://issues.apache.org/jira/browse/TRINIDAD-1630
>>
>> One reason is FacesBean uses propertyKeys, which allow additional
>> information like capabilities.
>>
>> Beyond that Andy Schwartz had actually taken a look at this previously.
>> Here's what he found.
>>
>> In theory the ideal solution should be to remove FacesBean in favor of
>> the new standard APIs. However, in practice, there are two issues:
>>
>> 1. We need to maintain backwards compatibility.
>> 2. Trinidad's FacesBean solution is more efficient than the standard
>> solution.
>>
>> Note that the compatibility issues (#1) mainly impact component/renderer
>> authors (not application developers), yet is still an important issue
>> for us.
>>
>> Regarding efficiency (#2)... FacesBean has two benefits over the
>> standard solution. First, FacesBean supports indexed property keys,
>> allowing for very efficient property lookups. Second, the Trinidad
>> approach avoids overhead involved in the JSF's attribute-property
>> transparency mechanism. When using the RI's implementation of
>> UIComponent.getAttributes().get("foo"), the following steps are performed:
>>
>> * First, look up the attribute in the attribute map.
>> * If not found, use reflection to call the property getter (eg.
>> getFoo()) on the component instance.
>> * The getter then performs yet another lookup on the StateHelper.
>>
>> This approach allows property look ups to be more easily customized via
>> subclassing (ie. by overriding accessor methods). Trinidad sacrifices
>> this flexibility for performance. Attribute lookups are routed directly
>> to the FacesBean without invoking component accessor methods.
>>
>> Thanks,
>>
>> Gabrielle
>>
>>
>> Matthias Wessendorf wrote:
>>
>>> quick comment...
>>>
>>> one reason to keep that structure is that the components (trinidad) offer
>>> more APIs and behavior.
>>>
>>> Also, not sure if we really want to go with JSF 2.0's partial state saving.
>>> Looks like FacesBean has still some advantages.
>>>
>>> Gabrielle, can you provide some data here ?
>>>
>>> -Matthias
>>>
>>> On Thu, Dec 3, 2009 at 11:20 AM, Jan-Kees van Andel
>>> <ja...@gmail.com> wrote:
>>>
>>>
>>>> Hey,
>>>>
>>>> I'm just asking this out of curiosity, so no offense intended. ;-)
>>>>
>>>> I see a lot of JSF 2.0 related activity in Trinidad and I was
>>>> wondering, why not leverage the JSF 2.0 code in MyFaces Core?
>>>> Are there (legacy) reasons to keep the UIX classes and not replace
>>>> them (maybe partially) with their JSF 2.0 equivalents?
>>>>
>>>> I can imagine that interoperability with other libraries increases
>>>> when Trinidad builds on (or extends) the JSF 2.0 API.
>>>>
>>>> Regards,
>>>> Jan-Kees
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
>
>
Re: Trinidad and JSF 2.0
Posted by Martin Koci <ma...@aura.cz>.
Hi,
regarding component.getAttributes() vs. bean.getProperty() performance:
do you have info under which circumstances is that difference
noticeable? I do some profiling on two apps: the first one is
trinidad12/jsf12 based and the second is JSF2 based. In both cases I
have same view but JSF2 based application uses UIComponent and newly
developed renderers instead trinidad. For example: CoreInputText ->
NewInputText and SimpleInputTextRenderer -> NewSimpleInputTextRenderer.
Algorithm in new renderers is the same as in trinidad but uses
getAttributes() directly.
I didn't notice a performance regression but maybe I look at wrong
places. Obviously it must cost something especially during render
response. Test is done for very complex view, loading is simulated as
100 concurrently working users - but YourKitProfiler shows very similar
results for render response phase. Memory profiling I didn't do yet.
Thanks,
Martin Kočí
Gabrielle Crawford píše v Čt 03. 12. 2009 v 09:29 -0800:
> Hi,
>
> Our implementation of facesBean in 1.2 already supported
> partialStateSaving, and for JSF 2 it's now a partialStateHolder
> https://issues.apache.org/jira/browse/TRINIDAD-1630
>
> One reason is FacesBean uses propertyKeys, which allow additional
> information like capabilities.
>
> Beyond that Andy Schwartz had actually taken a look at this previously.
> Here's what he found.
>
> In theory the ideal solution should be to remove FacesBean in favor of
> the new standard APIs. However, in practice, there are two issues:
>
> 1. We need to maintain backwards compatibility.
> 2. Trinidad's FacesBean solution is more efficient than the standard
> solution.
>
> Note that the compatibility issues (#1) mainly impact component/renderer
> authors (not application developers), yet is still an important issue
> for us.
>
> Regarding efficiency (#2)... FacesBean has two benefits over the
> standard solution. First, FacesBean supports indexed property keys,
> allowing for very efficient property lookups. Second, the Trinidad
> approach avoids overhead involved in the JSF's attribute-property
> transparency mechanism. When using the RI's implementation of
> UIComponent.getAttributes().get("foo"), the following steps are performed:
>
> * First, look up the attribute in the attribute map.
> * If not found, use reflection to call the property getter (eg.
> getFoo()) on the component instance.
> * The getter then performs yet another lookup on the StateHelper.
>
> This approach allows property look ups to be more easily customized via
> subclassing (ie. by overriding accessor methods). Trinidad sacrifices
> this flexibility for performance. Attribute lookups are routed directly
> to the FacesBean without invoking component accessor methods.
>
> Thanks,
>
> Gabrielle
>
>
> Matthias Wessendorf wrote:
> > quick comment...
> >
> > one reason to keep that structure is that the components (trinidad) offer
> > more APIs and behavior.
> >
> > Also, not sure if we really want to go with JSF 2.0's partial state saving.
> > Looks like FacesBean has still some advantages.
> >
> > Gabrielle, can you provide some data here ?
> >
> > -Matthias
> >
> > On Thu, Dec 3, 2009 at 11:20 AM, Jan-Kees van Andel
> > <ja...@gmail.com> wrote:
> >
> >> Hey,
> >>
> >> I'm just asking this out of curiosity, so no offense intended. ;-)
> >>
> >> I see a lot of JSF 2.0 related activity in Trinidad and I was
> >> wondering, why not leverage the JSF 2.0 code in MyFaces Core?
> >> Are there (legacy) reasons to keep the UIX classes and not replace
> >> them (maybe partially) with their JSF 2.0 equivalents?
> >>
> >> I can imagine that interoperability with other libraries increases
> >> when Trinidad builds on (or extends) the JSF 2.0 API.
> >>
> >> Regards,
> >> Jan-Kees
> >>
> >>
> >
> >
> >
> >
>
Re: Trinidad and JSF 2.0
Posted by Matthias Wessendorf <ma...@apache.org>.
On Thu, Dec 3, 2009 at 6:46 PM, Matthias Wessendorf <ma...@apache.org> wrote:
> lemme put that into our "nice" MoinMoin wiki.
> we can add stuff in the future there as well.
here:
http://wiki.apache.org/myfaces/Trinidad_FacesBean_and_PartialStateSaving
feel free to add numbers on performance etc
>
> -M
>
> On Thu, Dec 3, 2009 at 6:29 PM, Gabrielle Crawford
> <ga...@oracle.com> wrote:
>> Hi,
>>
>> Our implementation of facesBean in 1.2 already supported partialStateSaving,
>> and for JSF 2 it's now a partialStateHolder
>> https://issues.apache.org/jira/browse/TRINIDAD-1630
>>
>> One reason is FacesBean uses propertyKeys, which allow additional
>> information like capabilities.
>>
>> Beyond that Andy Schwartz had actually taken a look at this previously.
>> Here's what he found.
>>
>> In theory the ideal solution should be to remove FacesBean in favor of the
>> new standard APIs. However, in practice, there are two issues:
>>
>> 1. We need to maintain backwards compatibility.
>> 2. Trinidad's FacesBean solution is more efficient than the standard
>> solution.
>>
>> Note that the compatibility issues (#1) mainly impact component/renderer
>> authors (not application developers), yet is still an important issue for
>> us.
>>
>> Regarding efficiency (#2)... FacesBean has two benefits over the standard
>> solution. First, FacesBean supports indexed property keys, allowing for very
>> efficient property lookups. Second, the Trinidad approach avoids overhead
>> involved in the JSF's attribute-property transparency mechanism. When using
>> the RI's implementation of UIComponent.getAttributes().get("foo"), the
>> following steps are performed:
>>
>> * First, look up the attribute in the attribute map.
>> * If not found, use reflection to call the property getter (eg. getFoo())
>> on the component instance.
>> * The getter then performs yet another lookup on the StateHelper.
>>
>> This approach allows property look ups to be more easily customized via
>> subclassing (ie. by overriding accessor methods). Trinidad sacrifices this
>> flexibility for performance. Attribute lookups are routed directly to the
>> FacesBean without invoking component accessor methods.
>>
>> Thanks,
>>
>> Gabrielle
>>
>>
>> Matthias Wessendorf wrote:
>>>
>>> quick comment...
>>>
>>> one reason to keep that structure is that the components (trinidad) offer
>>> more APIs and behavior.
>>>
>>> Also, not sure if we really want to go with JSF 2.0's partial state
>>> saving.
>>> Looks like FacesBean has still some advantages.
>>>
>>> Gabrielle, can you provide some data here ?
>>>
>>> -Matthias
>>>
>>> On Thu, Dec 3, 2009 at 11:20 AM, Jan-Kees van Andel
>>> <ja...@gmail.com> wrote:
>>>
>>>>
>>>> Hey,
>>>>
>>>> I'm just asking this out of curiosity, so no offense intended. ;-)
>>>>
>>>> I see a lot of JSF 2.0 related activity in Trinidad and I was
>>>> wondering, why not leverage the JSF 2.0 code in MyFaces Core?
>>>> Are there (legacy) reasons to keep the UIX classes and not replace
>>>> them (maybe partially) with their JSF 2.0 equivalents?
>>>>
>>>> I can imagine that interoperability with other libraries increases
>>>> when Trinidad builds on (or extends) the JSF 2.0 API.
>>>>
>>>> Regards,
>>>> Jan-Kees
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: Trinidad and JSF 2.0
Posted by Matthias Wessendorf <ma...@apache.org>.
lemme put that into our "nice" MoinMoin wiki.
we can add stuff in the future there as well.
-M
On Thu, Dec 3, 2009 at 6:29 PM, Gabrielle Crawford
<ga...@oracle.com> wrote:
> Hi,
>
> Our implementation of facesBean in 1.2 already supported partialStateSaving,
> and for JSF 2 it's now a partialStateHolder
> https://issues.apache.org/jira/browse/TRINIDAD-1630
>
> One reason is FacesBean uses propertyKeys, which allow additional
> information like capabilities.
>
> Beyond that Andy Schwartz had actually taken a look at this previously.
> Here's what he found.
>
> In theory the ideal solution should be to remove FacesBean in favor of the
> new standard APIs. However, in practice, there are two issues:
>
> 1. We need to maintain backwards compatibility.
> 2. Trinidad's FacesBean solution is more efficient than the standard
> solution.
>
> Note that the compatibility issues (#1) mainly impact component/renderer
> authors (not application developers), yet is still an important issue for
> us.
>
> Regarding efficiency (#2)... FacesBean has two benefits over the standard
> solution. First, FacesBean supports indexed property keys, allowing for very
> efficient property lookups. Second, the Trinidad approach avoids overhead
> involved in the JSF's attribute-property transparency mechanism. When using
> the RI's implementation of UIComponent.getAttributes().get("foo"), the
> following steps are performed:
>
> * First, look up the attribute in the attribute map.
> * If not found, use reflection to call the property getter (eg. getFoo())
> on the component instance.
> * The getter then performs yet another lookup on the StateHelper.
>
> This approach allows property look ups to be more easily customized via
> subclassing (ie. by overriding accessor methods). Trinidad sacrifices this
> flexibility for performance. Attribute lookups are routed directly to the
> FacesBean without invoking component accessor methods.
>
> Thanks,
>
> Gabrielle
>
>
> Matthias Wessendorf wrote:
>>
>> quick comment...
>>
>> one reason to keep that structure is that the components (trinidad) offer
>> more APIs and behavior.
>>
>> Also, not sure if we really want to go with JSF 2.0's partial state
>> saving.
>> Looks like FacesBean has still some advantages.
>>
>> Gabrielle, can you provide some data here ?
>>
>> -Matthias
>>
>> On Thu, Dec 3, 2009 at 11:20 AM, Jan-Kees van Andel
>> <ja...@gmail.com> wrote:
>>
>>>
>>> Hey,
>>>
>>> I'm just asking this out of curiosity, so no offense intended. ;-)
>>>
>>> I see a lot of JSF 2.0 related activity in Trinidad and I was
>>> wondering, why not leverage the JSF 2.0 code in MyFaces Core?
>>> Are there (legacy) reasons to keep the UIX classes and not replace
>>> them (maybe partially) with their JSF 2.0 equivalents?
>>>
>>> I can imagine that interoperability with other libraries increases
>>> when Trinidad builds on (or extends) the JSF 2.0 API.
>>>
>>> Regards,
>>> Jan-Kees
>>>
>>>
>>
>>
>>
>>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: Trinidad and JSF 2.0
Posted by Gabrielle Crawford <ga...@oracle.com>.
Hi,
Our implementation of facesBean in 1.2 already supported
partialStateSaving, and for JSF 2 it's now a partialStateHolder
https://issues.apache.org/jira/browse/TRINIDAD-1630
One reason is FacesBean uses propertyKeys, which allow additional
information like capabilities.
Beyond that Andy Schwartz had actually taken a look at this previously.
Here's what he found.
In theory the ideal solution should be to remove FacesBean in favor of
the new standard APIs. However, in practice, there are two issues:
1. We need to maintain backwards compatibility.
2. Trinidad's FacesBean solution is more efficient than the standard
solution.
Note that the compatibility issues (#1) mainly impact component/renderer
authors (not application developers), yet is still an important issue
for us.
Regarding efficiency (#2)... FacesBean has two benefits over the
standard solution. First, FacesBean supports indexed property keys,
allowing for very efficient property lookups. Second, the Trinidad
approach avoids overhead involved in the JSF's attribute-property
transparency mechanism. When using the RI's implementation of
UIComponent.getAttributes().get("foo"), the following steps are performed:
* First, look up the attribute in the attribute map.
* If not found, use reflection to call the property getter (eg.
getFoo()) on the component instance.
* The getter then performs yet another lookup on the StateHelper.
This approach allows property look ups to be more easily customized via
subclassing (ie. by overriding accessor methods). Trinidad sacrifices
this flexibility for performance. Attribute lookups are routed directly
to the FacesBean without invoking component accessor methods.
Thanks,
Gabrielle
Matthias Wessendorf wrote:
> quick comment...
>
> one reason to keep that structure is that the components (trinidad) offer
> more APIs and behavior.
>
> Also, not sure if we really want to go with JSF 2.0's partial state saving.
> Looks like FacesBean has still some advantages.
>
> Gabrielle, can you provide some data here ?
>
> -Matthias
>
> On Thu, Dec 3, 2009 at 11:20 AM, Jan-Kees van Andel
> <ja...@gmail.com> wrote:
>
>> Hey,
>>
>> I'm just asking this out of curiosity, so no offense intended. ;-)
>>
>> I see a lot of JSF 2.0 related activity in Trinidad and I was
>> wondering, why not leverage the JSF 2.0 code in MyFaces Core?
>> Are there (legacy) reasons to keep the UIX classes and not replace
>> them (maybe partially) with their JSF 2.0 equivalents?
>>
>> I can imagine that interoperability with other libraries increases
>> when Trinidad builds on (or extends) the JSF 2.0 API.
>>
>> Regards,
>> Jan-Kees
>>
>>
>
>
>
>
Re: Trinidad and JSF 2.0
Posted by Luka Surija <lu...@iytim.hr>.
Hi Kito,
Working name of the project is CloudOffice.
Set of services for small companies. (hosted IMAP mail, web hosting with
our CMS and web application as Business Suite).
This business suite contains
- collaboration module (knowledge base, forum, journaling, todo-s,
calendar, ticketing and similar stuff)
- sales module (offers, orders, invoices)
- finance (incomes, outcomes, reports).
This web application will be hosted and offered as SaaS for about
100$/month for company till 5 employees.
Background technology is
Glassfish V2
Trinidad 1.2.12
Facelets 1.1.13 (Facelets 1.1.14 doesn't work in this environment)
Orchestra
Also our "Control Panel" is implemented in this technology.
Till now we had this web application writen in ADF Faces, but currently
we are doing a transition to Trinidad and Facelets.
Luka Surija
On 12/09/2009 05:32 PM, Kito Mann wrote:
> Luka, what project are you working on?
> ---
> Kito D. Mann | twitter: kito99 | Author, JSF in Action
> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
> twitter: jsfcentral
> +1 203-404-4848 x3
>
> JSF Summit Conference Dec 1st-4th in Orlando: http://www.jsfsummit.com
>
>
>
>
> On Wed, Dec 9, 2009 at 10:20 AM, Luka Surija<lu...@iytim.hr> wrote:
>
>> On 12/09/2009 01:22 PM, Matthias Wessendorf wrote:
>>
>>> On Wed, Dec 9, 2009 at 11:41 AM, Luka Surija<lu...@iytim.hr> wrote:
>>>
>>>
>>>> Hi,
>>>> Sorry for "jumping into the topic" but I have a question regarding
>>>> compatibility issue.
>>>> Does it mean that using FacesBean instead of JSF 2.0 PSS can introduce
>>>> possible component incompatibility with another JSF 2 libraries like
>>>> RichFaces, PrimeFaces, IceFaces?. Or did I miss something?
>>>>
>>>>
>>> nope; but even with JSF 2.0 I still think there maybe some issues.
>>> As the JS/Ajax is not complete on the standard (e.g. lack of support
>>> for uploads) but all major frameworks have that. I expect a mixture of
>>> vanilla JS and custom stuff... Spec will evolve over time....
>>>
>>>
>> Yeah, that sucks also. What's the point of spec and standards when
>> implementations aren't compatible.
>>
>>>
>>>
>>>> My personal opinion is that Trinidad will gain more users if there's no
>>>> more
>>>> compatibility issues with other JSF libraries. Trinidadis relay a
>>>> powerful
>>>> library, but has lack of some visual components. In that case more
>>>> developers will decide to go with trinidad as ground library and using
>>>> other
>>>> components as add-ons.
>>>>
>>>>
>>> most big issue is that the default skin totally sucks :-)
>>>
>>>
>> After we finish our product we are wiling to give you our skin. It's not
>> perfect but is much better then default one.
>>
>>>
>>>
>>>> Regards,
>>>>
>>>> Luka Surija
>>>>
>>>>
>>>>
>>>> Matthias Wessendorf wrote:
>>>>
>>>>
>>>>> quick comment...
>>>>>
>>>>> one reason to keep that structure is that the components (trinidad)
>>>>> offer
>>>>> more APIs and behavior.
>>>>>
>>>>> Also, not sure if we really want to go with JSF 2.0's partial state
>>>>> saving.
>>>>> Looks like FacesBean has still some advantages.
>>>>>
>>>>> Gabrielle, can you provide some data here ?
>>>>>
>>>>> -Matthias
>>>>>
>>>>> On Thu, Dec 3, 2009 at 11:20 AM, Jan-Kees van Andel
>>>>> <ja...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hey,
>>>>>>
>>>>>> I'm just asking this out of curiosity, so no offense intended. ;-)
>>>>>>
>>>>>> I see a lot of JSF 2.0 related activity in Trinidad and I was
>>>>>> wondering, why not leverage the JSF 2.0 code in MyFaces Core?
>>>>>> Are there (legacy) reasons to keep the UIX classes and not replace
>>>>>> them (maybe partially) with their JSF 2.0 equivalents?
>>>>>>
>>>>>> I can imagine that interoperability with other libraries increases
>>>>>> when Trinidad builds on (or extends) the JSF 2.0 API.
>>>>>>
>>>>>> Regards,
>>>>>> Jan-Kees
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
Re: Trinidad and JSF 2.0
Posted by Kito Mann <ki...@virtua.com>.
Luka, what project are you working on?
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
twitter: jsfcentral
+1 203-404-4848 x3
JSF Summit Conference Dec 1st-4th in Orlando: http://www.jsfsummit.com
On Wed, Dec 9, 2009 at 10:20 AM, Luka Surija <lu...@iytim.hr> wrote:
>
> On 12/09/2009 01:22 PM, Matthias Wessendorf wrote:
>>
>> On Wed, Dec 9, 2009 at 11:41 AM, Luka Surija<lu...@iytim.hr> wrote:
>>
>>>
>>> Hi,
>>> Sorry for "jumping into the topic" but I have a question regarding
>>> compatibility issue.
>>> Does it mean that using FacesBean instead of JSF 2.0 PSS can introduce
>>> possible component incompatibility with another JSF 2 libraries like
>>> RichFaces, PrimeFaces, IceFaces?. Or did I miss something?
>>>
>>
>> nope; but even with JSF 2.0 I still think there maybe some issues.
>> As the JS/Ajax is not complete on the standard (e.g. lack of support
>> for uploads) but all major frameworks have that. I expect a mixture of
>> vanilla JS and custom stuff... Spec will evolve over time....
>>
>
> Yeah, that sucks also. What's the point of spec and standards when
> implementations aren't compatible.
>>
>>
>>>
>>> My personal opinion is that Trinidad will gain more users if there's no
>>> more
>>> compatibility issues with other JSF libraries. Trinidadis relay a
>>> powerful
>>> library, but has lack of some visual components. In that case more
>>> developers will decide to go with trinidad as ground library and using
>>> other
>>> components as add-ons.
>>>
>>
>> most big issue is that the default skin totally sucks :-)
>>
>
> After we finish our product we are wiling to give you our skin. It's not
> perfect but is much better then default one.
>>
>>
>>>
>>> Regards,
>>>
>>> Luka Surija
>>>
>>>
>>>
>>> Matthias Wessendorf wrote:
>>>
>>>>
>>>> quick comment...
>>>>
>>>> one reason to keep that structure is that the components (trinidad)
>>>> offer
>>>> more APIs and behavior.
>>>>
>>>> Also, not sure if we really want to go with JSF 2.0's partial state
>>>> saving.
>>>> Looks like FacesBean has still some advantages.
>>>>
>>>> Gabrielle, can you provide some data here ?
>>>>
>>>> -Matthias
>>>>
>>>> On Thu, Dec 3, 2009 at 11:20 AM, Jan-Kees van Andel
>>>> <ja...@gmail.com> wrote:
>>>>
>>>>
>>>>>
>>>>> Hey,
>>>>>
>>>>> I'm just asking this out of curiosity, so no offense intended. ;-)
>>>>>
>>>>> I see a lot of JSF 2.0 related activity in Trinidad and I was
>>>>> wondering, why not leverage the JSF 2.0 code in MyFaces Core?
>>>>> Are there (legacy) reasons to keep the UIX classes and not replace
>>>>> them (maybe partially) with their JSF 2.0 equivalents?
>>>>>
>>>>> I can imagine that interoperability with other libraries increases
>>>>> when Trinidad builds on (or extends) the JSF 2.0 API.
>>>>>
>>>>> Regards,
>>>>> Jan-Kees
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
Re: Trinidad and JSF 2.0
Posted by Luka Surija <lu...@iytim.hr>.
On 12/09/2009 01:22 PM, Matthias Wessendorf wrote:
> On Wed, Dec 9, 2009 at 11:41 AM, Luka Surija<lu...@iytim.hr> wrote:
>
>> Hi,
>> Sorry for "jumping into the topic" but I have a question regarding
>> compatibility issue.
>> Does it mean that using FacesBean instead of JSF 2.0 PSS can introduce
>> possible component incompatibility with another JSF 2 libraries like
>> RichFaces, PrimeFaces, IceFaces?. Or did I miss something?
>>
> nope; but even with JSF 2.0 I still think there maybe some issues.
> As the JS/Ajax is not complete on the standard (e.g. lack of support
> for uploads) but all major frameworks have that. I expect a mixture of
> vanilla JS and custom stuff... Spec will evolve over time....
>
Yeah, that sucks also. What's the point of spec and standards when
implementations aren't compatible.
>
>> My personal opinion is that Trinidad will gain more users if there's no more
>> compatibility issues with other JSF libraries. Trinidadis relay a powerful
>> library, but has lack of some visual components. In that case more
>> developers will decide to go with trinidad as ground library and using other
>> components as add-ons.
>>
> most big issue is that the default skin totally sucks :-)
>
After we finish our product we are wiling to give you our skin. It's not
perfect but is much better then default one.
>
>> Regards,
>>
>> Luka Surija
>>
>>
>>
>> Matthias Wessendorf wrote:
>>
>>> quick comment...
>>>
>>> one reason to keep that structure is that the components (trinidad) offer
>>> more APIs and behavior.
>>>
>>> Also, not sure if we really want to go with JSF 2.0's partial state
>>> saving.
>>> Looks like FacesBean has still some advantages.
>>>
>>> Gabrielle, can you provide some data here ?
>>>
>>> -Matthias
>>>
>>> On Thu, Dec 3, 2009 at 11:20 AM, Jan-Kees van Andel
>>> <ja...@gmail.com> wrote:
>>>
>>>
>>>> Hey,
>>>>
>>>> I'm just asking this out of curiosity, so no offense intended. ;-)
>>>>
>>>> I see a lot of JSF 2.0 related activity in Trinidad and I was
>>>> wondering, why not leverage the JSF 2.0 code in MyFaces Core?
>>>> Are there (legacy) reasons to keep the UIX classes and not replace
>>>> them (maybe partially) with their JSF 2.0 equivalents?
>>>>
>>>> I can imagine that interoperability with other libraries increases
>>>> when Trinidad builds on (or extends) the JSF 2.0 API.
>>>>
>>>> Regards,
>>>> Jan-Kees
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
>
>
Re: Trinidad and JSF 2.0
Posted by Matthias Wessendorf <ma...@apache.org>.
On Wed, Dec 9, 2009 at 11:41 AM, Luka Surija <lu...@iytim.hr> wrote:
> Hi,
> Sorry for "jumping into the topic" but I have a question regarding
> compatibility issue.
> Does it mean that using FacesBean instead of JSF 2.0 PSS can introduce
> possible component incompatibility with another JSF 2 libraries like
> RichFaces, PrimeFaces, IceFaces?. Or did I miss something?
nope; but even with JSF 2.0 I still think there maybe some issues.
As the JS/Ajax is not complete on the standard (e.g. lack of support
for uploads) but all major frameworks have that. I expect a mixture of
vanilla JS and custom stuff... Spec will evolve over time....
>
> My personal opinion is that Trinidad will gain more users if there's no more
> compatibility issues with other JSF libraries. Trinidadis relay a powerful
> library, but has lack of some visual components. In that case more
> developers will decide to go with trinidad as ground library and using other
> components as add-ons.
most big issue is that the default skin totally sucks :-)
>
> Regards,
>
> Luka Surija
>
>
>
> Matthias Wessendorf wrote:
>>
>> quick comment...
>>
>> one reason to keep that structure is that the components (trinidad) offer
>> more APIs and behavior.
>>
>> Also, not sure if we really want to go with JSF 2.0's partial state
>> saving.
>> Looks like FacesBean has still some advantages.
>>
>> Gabrielle, can you provide some data here ?
>>
>> -Matthias
>>
>> On Thu, Dec 3, 2009 at 11:20 AM, Jan-Kees van Andel
>> <ja...@gmail.com> wrote:
>>
>>>
>>> Hey,
>>>
>>> I'm just asking this out of curiosity, so no offense intended. ;-)
>>>
>>> I see a lot of JSF 2.0 related activity in Trinidad and I was
>>> wondering, why not leverage the JSF 2.0 code in MyFaces Core?
>>> Are there (legacy) reasons to keep the UIX classes and not replace
>>> them (maybe partially) with their JSF 2.0 equivalents?
>>>
>>> I can imagine that interoperability with other libraries increases
>>> when Trinidad builds on (or extends) the JSF 2.0 API.
>>>
>>> Regards,
>>> Jan-Kees
>>>
>>>
>>
>>
>>
>>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: Trinidad and JSF 2.0
Posted by Luka Surija <lu...@iytim.hr>.
Hi,
Sorry for "jumping into the topic" but I have a question regarding
compatibility issue.
Does it mean that using FacesBean instead of JSF 2.0 PSS can introduce
possible component incompatibility with another JSF 2 libraries like
RichFaces, PrimeFaces, IceFaces?. Or did I miss something?
My personal opinion is that Trinidad will gain more users if there's no
more compatibility issues with other JSF libraries. Trinidadis relay a
powerful library, but has lack of some visual components. In that case
more developers will decide to go with trinidad as ground library and
using other components as add-ons.
Regards,
Luka Surija
Matthias Wessendorf wrote:
> quick comment...
>
> one reason to keep that structure is that the components (trinidad) offer
> more APIs and behavior.
>
> Also, not sure if we really want to go with JSF 2.0's partial state saving.
> Looks like FacesBean has still some advantages.
>
> Gabrielle, can you provide some data here ?
>
> -Matthias
>
> On Thu, Dec 3, 2009 at 11:20 AM, Jan-Kees van Andel
> <ja...@gmail.com> wrote:
>
>> Hey,
>>
>> I'm just asking this out of curiosity, so no offense intended. ;-)
>>
>> I see a lot of JSF 2.0 related activity in Trinidad and I was
>> wondering, why not leverage the JSF 2.0 code in MyFaces Core?
>> Are there (legacy) reasons to keep the UIX classes and not replace
>> them (maybe partially) with their JSF 2.0 equivalents?
>>
>> I can imagine that interoperability with other libraries increases
>> when Trinidad builds on (or extends) the JSF 2.0 API.
>>
>> Regards,
>> Jan-Kees
>>
>>
>
>
>
>
Re: Trinidad and JSF 2.0
Posted by Kito Mann <ki...@virtua.com>.
Matthias,
Is there a way to support the standard APIs but still uses FacesBean internally?
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
twitter: jsfcentral
+1 203-404-4848 x3
JSF Summit Conference Dec 1st-4th in Orlando: http://www.jsfsummit.com
On Thu, Dec 3, 2009 at 5:47 AM, Matthias Wessendorf <ma...@apache.org> wrote:
> quick comment...
>
> one reason to keep that structure is that the components (trinidad) offer
> more APIs and behavior.
>
> Also, not sure if we really want to go with JSF 2.0's partial state saving.
> Looks like FacesBean has still some advantages.
>
> Gabrielle, can you provide some data here ?
>
> -Matthias
>
> On Thu, Dec 3, 2009 at 11:20 AM, Jan-Kees van Andel
> <ja...@gmail.com> wrote:
>> Hey,
>>
>> I'm just asking this out of curiosity, so no offense intended. ;-)
>>
>> I see a lot of JSF 2.0 related activity in Trinidad and I was
>> wondering, why not leverage the JSF 2.0 code in MyFaces Core?
>> Are there (legacy) reasons to keep the UIX classes and not replace
>> them (maybe partially) with their JSF 2.0 equivalents?
>>
>> I can imagine that interoperability with other libraries increases
>> when Trinidad builds on (or extends) the JSF 2.0 API.
>>
>> Regards,
>> Jan-Kees
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
Re: Trinidad and JSF 2.0
Posted by Matthias Wessendorf <ma...@apache.org>.
quick comment...
one reason to keep that structure is that the components (trinidad) offer
more APIs and behavior.
Also, not sure if we really want to go with JSF 2.0's partial state saving.
Looks like FacesBean has still some advantages.
Gabrielle, can you provide some data here ?
-Matthias
On Thu, Dec 3, 2009 at 11:20 AM, Jan-Kees van Andel
<ja...@gmail.com> wrote:
> Hey,
>
> I'm just asking this out of curiosity, so no offense intended. ;-)
>
> I see a lot of JSF 2.0 related activity in Trinidad and I was
> wondering, why not leverage the JSF 2.0 code in MyFaces Core?
> Are there (legacy) reasons to keep the UIX classes and not replace
> them (maybe partially) with their JSF 2.0 equivalents?
>
> I can imagine that interoperability with other libraries increases
> when Trinidad builds on (or extends) the JSF 2.0 API.
>
> Regards,
> Jan-Kees
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf