myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hazem Saleh <haz...@apache.org>
Subject Re: [Trinidad][api]TRINIDAD-1857 Add a Map associated with each window or tab that the user is interacting with
Date Wed, 21 Jul 2010 20:20:16 GMT
+1

On Wed, Jul 21, 2010 at 11:00 PM, Gerhard Petracek <
gerhard.petracek@gmail.com> wrote:

> hi blake,
>
> basically you can use an external map in cdi context implementations.
> however, with cdi you shouldn't do that. "everybody" could just change or
> clear it and you would bypass important mechanisms of cdi. i would vote -1
> for such an approach. if you plan that trinidad hosts an own window scope
> (based on cdi), you have to re-implement parts which are available in
> portable cdi extensions like codi. or trinidad just provides some additional
> events which would allow a better compatibility (if there are issues).
>
> plain trinidad ... jsf + trinidad without any other lib (in this case: libs
> for additional scopes).
>
> @trinidad scopes:
> that's my point - besides some other great frameworks, we now have a spec.
> for scopes which allows portable extensions. imo trinidad is just the wrong
> place for adding new scopes. users can just use e.g. trinidad dialogs in
> combination with the access scope provided by libs like codi.
> and with trinidad support modules we could close potential gaps.
>
> regards,
> gerhard
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
> 2010/7/21 Blake Sullivan <blake.sullivan@oracle.com>
>
>>
>> On Jul 21, 2010, at 10:05 AM, Gerhard Petracek wrote:
>>
>> hi blake,
>>
>> @trinidad window map & cdi:
>> we are just interested in some special events like a page-refresh
>> (triggered by the user).
>> everything else is handled internally. -> (currently) i don't see a reason
>> for using such an external map.
>>
>> I'm not sure what you are asking here.  There should be a small number of
>> requirements on the provider of a scope implementation.  The CDI code should
>> be able to plug into any scope provider.  I would assume that part of that
>> contract would be providing a Map as a storage abstraction and some kind of
>> lifecycle.  If Trinidad users want to use CDI to inject beans into the
>> window scope, it would be nice for them to be able to configure Trinidad as
>> the implementor of the window scope.
>>
>>
>> @stand-alone trinidad window map:
>> do you mean there are some internal project guidelines like:
>>  the project has to use plain trinidad.
>> ?
>>
>> I'm not sure what you mean by "plain".  The requirement is that the
>> Trinidad WindowManager needs to be running on the requests that want to use
>> the Trinidad apis to access the per-window map, since the window map is
>> retrieved from the current window.
>>
>>
>> @page flow scope:
>> that's a similar story - besides @WindowScoped codi provides
>> @ConversationScoped (similar to the conversations of orchestra) as well as
>> @ViewAccessScoped (similar to the access scope of orchestra).
>>
>> That's right and the implementations of all of the scopes are pluggable in
>> Trinidad so that they can delegate to any installed implementation.
>>
>> -- Blake Sullivan
>>
>>
>> regards,
>> gerhard
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>>
>> 2010/7/21 Blake Sullivan <blake.sullivan@oracle.com>
>>
>>>
>>> On Jul 21, 2010, at 5:02 AM, Gerhard Petracek wrote:
>>>
>>> hi mark,
>>>
>>> nobody said that it would harm (at least i'm not aware of technical
>>> issues).
>>> (maybe some people would use it even though they shouldn't - e.g. because
>>> they have an alternative which should be used in their application/s.)
>>> furthermore, i agree with martin - most projects are using (or will use)
>>> one of the mentioned frameworks.
>>>
>>> the questions are:
>>> who would use this feature?
>>>
>>> Anyone who needed to store information on a per window basis and could
>>> live without managed bean support.  We already had several teams trying to
>>> build this on their own.  The finer-grained scopes, such as page flow scope,
>>> should be built on top of this directly. As teams have been dealing with
>>> fail-over issues, they are finding that they want this.
>>>
>>>  - new projects? i don't think so.
>>>
>>> If they had the above issues, sure.
>>>
>>>   - existing projects? would they upgrade to a new version of trinidad
>>> just for using this feature?
>>>
>>> I don't understand.  If the bar for new features is that they must be the
>>> driving force for customers to upgrade, very few features would be added to
>>> any project.
>>>
>>> -- Blake Sullivan
>>>
>>>
>>> maybe it's the right time to discuss our plans for the future of
>>> trinidad. (at least if we should use the maven shade plugin for modularizing
>>> trinidad. in such a case we could also provide an all-in-one package via
>>> special modules. so users won't see any difference, if they prefer the
>>> existing monolithic package.)
>>>
>>> regards,
>>> gerhard
>>>
>>> http://www.irian.at
>>>
>>> Your JSF powerhouse -
>>> JSF Consulting, Development and
>>> Courses in English and German
>>>
>>> Professional Support for Apache MyFaces
>>>
>>>
>>> 2010/7/21 Mark Struberg <struberg@yahoo.de>
>>>
>>>> Hmm difficult topic.
>>>>
>>>> Please allow me a few questions:
>>>>
>>>> a.) Trinidad components would still work with using either Orchestra
>>>> conversations or CODI?
>>>> b) You are not relying on other components or the users using your
>>>> conversation
>>>> stuff if they don't like?
>>>> c) if the user doesn't make use of this feature, it will not pollute the
>>>> viewRoot or cause heavy performance hits?
>>>>
>>>> If all this is ok, then there is imo no argument against adding it to
>>>> Trinidad.
>>>> This doesn't mean I like it either, but it doesn't hurt at least ;)
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>> >
>>>> >From: Gerhard Petracek <gerhard.petracek@gmail.com>
>>>> >To: MyFaces Development <dev@myfaces.apache.org>
>>>> >Sent: Wed, July 21, 2010 10:16:23 AM
>>>> >Subject: Re: [Trinidad][api]TRINIDAD-1857 Add a Map associated with
>>>> each  window
>>>> >
>>>> >or tab that the user is interacting with
>>>> >
>>>> >i agree with martin.
>>>> >
>>>> >
>>>> >regards,
>>>> >gerhard
>>>> >
>>>> >http://www.irian.at
>>>> >
>>>> >Your JSF powerhouse -
>>>> >JSF Consulting, Development and
>>>> >Courses in English and German
>>>> >
>>>> >Professional Support for Apache MyFaces
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >2010/7/21 Martin Marinschek <mmarinschek@apache.org>
>>>> >
>>>> >Hi Matthias,
>>>> >>
>>>> >>
>>>> >>> Not everybody is using CDI and/or Spring.
>>>> >>
>>>> >>well, in the real world and a little while in the future, there is
not
>>>> >>many people who will not have one of these frameworks in their
>>>> >>applications.
>>>> >>
>>>> >>
>>>> >>> I think, on long term we may want one clean and independent
API,
>>>> where
>>>> >>> all these projects offer an implementation for a window/event
>>>> system:
>>>> >>> -CODI
>>>> >>> -Orchestra
>>>> >>> -Trinidad
>>>> >>> -etc
>>>> >>>
>>>> >>> However, right now, Trinidad has the base already and adding
a new
>>>> >>> toolset to the belt feels kinda wrong.
>>>> >>> Again +1 on this to be inside of Trinidad.
>>>> >>>
>>>> >>> This does not mean that we could work on a better future version
of
>>>> a
>>>> >>> more unified API, for this. Right?
>>>> >>
>>>> >>yes, this is what we could and what we should. Why not take this
>>>> >>addition as a reason to do this right now? If we donĀ“t take such
>>>> >>additions as a reason to do this, what else will be our reason?
>>>> >>
>>>> >>best regards,
>>>> >>
>>>> >>Martin
>>>> >>
>>>> >>--
>>>> >>
>>>> >>
>>>> >>http://www.irian.at
>>>> >>
>>>> >>Your JSF powerhouse -
>>>> >>JSF Consulting, Development and
>>>> >>Courses in English and German
>>>> >>
>>>> >>Professional Support for Apache MyFaces
>>>> >>
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>


-- 
Hazem Ahmed Saleh Ahmed

Author of (The Definitive Guide to Apache MyFaces and Facelets):
http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370
http://www.amazon.com/-/e/B002M052KY

Web blog: http://hazems.blogetery.com/

[Web 2.0] Mashups Integration with JSF:
http://code.google.com/p/mashups4jsf/

Mime
View raw message