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 20:00:52 GMT
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
>>> >>
>>> >
>>>
>>>
>>>
>>>
>>
>>
>
>

Mime
View raw message