myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
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 21:08:53 GMT
imo martin summarized the "objection" perfectly [1].

regards,
gerhard

[1] http://www.mail-archive.com/dev@myfaces.apache.org/msg47448.html

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 1:00 PM, Gerhard Petracek 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.
>
> That's assuming that the requirements for a scope provider didn't include
> notification when the contents changed.  Since it would, that isn't a
> problem.
>
>  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.
>
> That's also not what I said.  I said that Trinidad users that want to have
> the abstraction of a per-window Map provided by Trinidad act as a full scope
> should be able to integrate this with CODI.  And that such schemes should
> allow such a separation of responsibilities.
>
> or trinidad just provides some additional events which would allow a better
> compatibility (if there are issues).
>
> Which events?
>
>
> plain trinidad ... jsf + trinidad without any other lib (in this case: libs
> for additional scopes).
>
> I'm not sure what you mean here.   I should be able to use Trinidad and JSF
> and have a per-window Map if I have a WindowManager installed with Trinidad.
>
>
>
> @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.
>
> We explicitly did not add a scope in that sense.  We added a per-window
> Map.  There is no out-of-box bean management.  The system could be
> configured to map this to a real scope and that could be implemented as an
> out-of-the-box feature later, but that is also implementation.
>
>  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.
>
> Users can already do that if they want.  It would be nice to have a
> CODI-Trinidad module, but that should not be required for customers who
> don't need CDI.
>
> I am still trying to get my head around is your specific complaint.
>
> Do you object to Trinidad making it easier for Trinidad customers to
> associate Objects with their windows?  That is specifically what the api
> question is.  As I have written a number of times, they can already wire
> this up by themselves today, so it seems cruel to prevent us from making it
> easy for them to do this correctly. If the complaint is that Trinidad has
> per-window Objects, the feature is already in there and make perfect sense
> for a UI framework.
>
> -- 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 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
>>>> >>
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Mime
View raw message