myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Wessendorf <mat...@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 07:35:55 GMT
Hi guys,

generally I'd like to see this in Trinidad for reasons as stated earlier.

few more comments inline:

On Wed, Jul 21, 2010 at 4:52 AM, Gerhard Petracek
<gerhard.petracek@gmail.com> wrote:
> hi blake,
> @events:
> libs like codi might benefit from such additional events. we could think
> about a trinidad-support module.

+1 on such a codi-trinidad module

> @trinidad window map:
> i'm still not convinced. i would use a scope provided by libs like
> orchestra, codi,...
> if there aren't quite a lot of users who use trinidad without such
> additional frameworks, i would vote -0.

Not everybody is using CDI and/or Spring.

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?

-Matthias

> 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>
>>
>> Gerhard,
>> Do you have any comments on this?
>> -- Blake Sullivan
>> On Jul 19, 2010, at 2:37 PM, Blake Sullivan wrote:
>>
>> The Trinidad WindowManager defines a lifecycle for windows which includes
>> events for windows being created, unloaded, reloaded closed.  etc.  The
>> implementation is free to use as much JavaScript as it needs to in order to
>> ensure better results, including more prompt clean up of resources.
>>  However, from an api standpoint, that is neither here nor there.  Trinidad
>> already has Window objects and it would seem natural that a consumer of the
>> Window object would like to associate state with it.  The first place they
>> would look is on the Window object itself.  From an api perspective, what is
>> wrong with a method on the Window object that returns a Map?
>>  Consumers already use the fact that Windows have stable identifiers and
>> fire lifecycle events to manage the storage themselves.  This api handles
>> that task for the simpler users of the Window class.
>> -- Blake Sullivan
>>
>> On Jul 19, 2010, at 2:14 PM, Gerhard Petracek wrote:
>>
>> hi blake,
>> why do you think trinidad would provide a better implementation?
>> 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/19 Blake Sullivan <blake.sullivan@oracle.com>
>>>
>>> Gerhard,
>>> If users want to use those implementations they should be able to and
>>> Trinidad should be able to delegate to them.  However, if Trinidad has a
>>> Trinidad WindowManager installed, that WindowManager can do a much better
>>> job than any of those implementations regarding managing the lifecycle of
>>> the scope.  In addition, if the application, or framework itself wants to
>>> programmatically shove objects into the Map representing this scope (which
>>> has always existed at least in the implementation), its weird that it should
>>> all of a sudden have to start using a new set of apis.
>>> -- Blake Sullivan
>>>
>>> On Jul 19, 2010, at 1:01 PM, Gerhard Petracek wrote:
>>>
>>> hi blake,
>>> no - my suggestion was that it should be a feature which can be used
>>> independently.
>>> if users need a window scope and they use
>>>  * cdi, they can use codi
>>>  * spring, they can use orchestra (if we implement it there as well)
>>>  * ~plain jsf, they should be able to use a simpler version which is
>>> independent of a special component lib (e.g. provided by myfaces-commons)
>>> 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/19 Blake Sullivan <blake.sullivan@oracle.com>
>>>>
>>>> Thanks Gerhard.
>>>> Did you want Trinidad to be configurable to delegate to Orchestra if its
>>>> available, in this case?
>>>> -- Blake Sullivan
>>>>
>>>> On Jul 19, 2010, at 12:23 AM, Gerhard Petracek wrote:
>>>>
>>>> hi blake,
>>>> it's similar to the conversation context id of orchestra - we just have
>>>> an id for every window.
>>>> (in case of @WindowScoped we just add a component to the view-root
>>>> (before the page gets rendered).
>>>> the window id is stored as state of the component. in case of jsf 1.2
>>>> and redirects we need an url parameter for the get-request. the
>>>> implementation is pluggable - so it's possible to provide a custom
>>>> implementation for storing and restoring the information. in case of jsf
>>>> 2.0+ and redirects you won't see an url parameter. in this case we use the
>>>> flash scope to store the required information.)
>>>>
>>>> i'll add all the details to the wiki page [1]. i've finished the
>>>> implementation of the first draft by the end of last week. so i've to
>>>> cleanup some parts and i've to write further javadoc and documentation.
>>>> regards,
>>>> gerhard
>>>> [1] http://wiki.apache.org/myfaces/Extensions/CDI/DevDoc/Conversations
>>>> http://www.irian.at
>>>>
>>>> Your JSF powerhouse -
>>>> JSF Consulting, Development and
>>>> Courses in English and German
>>>>
>>>> Professional Support for Apache MyFaces
>>>>
>>>>
>>>> 2010/7/19 Blake Sullivan <blake.sullivan@oracle.com>
>>>>>
>>>>> What code actually associates the scope with the browser windows?  For
>>>>> example, in Trinidad, we have a WindowManager tasked with that job.
>>>>> -- Blake Sullivan
>>>>> On Jul 17, 2010, at 1:47 PM, Gerhard Petracek wrote:
>>>>>
>>>>> hi blake,
>>>>> @WindowScoped (provided by myfaces codi) is a portable extension for
>>>>> cdi. therefore not every project will be able to use it.
>>>>> anyway, imo it would be better to provide a cdi independent version of
>>>>> it e.g. in myfaces-orchestra and/or myfaces-commons.
>>>>> 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/17 Jakob Korherr <jakob.korherr@gmail.com>
>>>>>>
>>>>>> Hi Blake,
>>>>>>
>>>>>> Just FYI: we have also implemented a window scope for MyFaces Codi
>>>>>> (ext-cdi). Maybe you want to take a look at it ;)
>>>>>>
>>>>>> Regards,
>>>>>> Jakob
>>>>>>
>>>>>> 2010/7/17 Blake Sullivan <blake.sullivan@oracle.com>
>>>>>>>
>>>>>>> We currently have scopes for:
>>>>>>> Application
>>>>>>> Session
>>>>>>> PageFlow
>>>>>>> View
>>>>>>>
>>>>>>> I propose that we add a Map associated with each window or tab
that
>>>>>>> the user is interacting with.  This would slop into the scope
hierarchy
>>>>>>> between the Session and PageFlow scopes.  We would also expose
the storage
>>>>>>> for the current window on the RequestContext.  If no WindowManager
was
>>>>>>> exposed and therefore there was no current Window, this Map would
be the
>>>>>>> SessionMap.
>>>>>>>
>>>>>>> For high availability, each of the attributes stored in a Window's
>>>>>>> map would be stored as separate attributes in the Session.
>>>>>>>
>>>>>>> At least initially, we would not expose this map directly through
its
>>>>>>> own top-level windowScope EL property.
>>>>>>>
>>>>>>> Proposed apis:
>>>>>>>
>>>>>>> RequestContext:
>>>>>>>
>>>>>>>  /**
>>>>>>>   * Returns a Map of objects associated with the current window
if
>>>>>>> any.  If there is no
>>>>>>>   * current window, the Session Map is returned.
>>>>>>>   * @return Map for storing objects associated with the current
>>>>>>> window.
>>>>>>>   * @see org.apache.myfaces.trinidad.context.Window#getWindowMap
>>>>>>>   */
>>>>>>>  public Map<String, Object> getWindowMap()
>>>>>>>
>>>>>>> Window
>>>>>>>
>>>>>>>  /**
>>>>>>>   * Returns the Map for storing data associated with this Window
>>>>>>> object.  If the environment is
>>>>>>>   * configured for fail-over, the contents of this Map must
be
>>>>>>> Serializable.
>>>>>>>   * @return The client data storage Map.
>>>>>>>   */
>>>>>>>  public abstract Map<String, Object> getWindowMap();
>>>>>>>
>>>>>>> Since we would provide a default implementation of getWindowMap
using
>>>>>>> import org.apache.myfaces.trinidadinternal.util.SubKeyMap, we
would also
>>>>>>> have to make SubKeyMap public as well.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jakob Korherr
>>>>>>
>>>>>> blog: http://www.jakobk.com
>>>>>> twitter: http://twitter.com/jakobkorherr
>>>>>> work: http://www.irian.at
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Mime
View raw message