+1 on this
On Sat, Jul 17, 2010 at 12:16 AM, Blake Sullivan
blake.sulli...@oracle.com wrote:
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
On Mon, Jul 19, 2010 at 10:01 PM, Gerhard Petracek
gerhard.petra...@gmail.com 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
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.petra...@gmail.com wrote:
hi blake,
@events:
libs like codi might benefit from such additional events. we could think
about
Hi guys,
right now for this feature, I think a close integration to Trinidad
does make sense,
since we already have window handling, including lifecycle and an
(complete) event system.
Hence the proposed API is just a small addition.
certainly this makes sense from your current point of
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
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 mmarinsc...@apache.org
Hi Matthias,
Not everybody is using CDI and/or
On Wed, Jul 21, 2010 at 9:44 AM, Martin Marinschek
mmarinsc...@apache.org wrote:
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
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
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
On Wed, Jul 21, 2010 at 2:02 PM, Gerhard Petracek
gerhard.petra...@gmail.com 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
hi,
an optional trinidad-support module for codi, orchestra,... could use the
special events of trinidad. - these trinidad-support modules would have a
dependency to trinidad (and not the other way round). if users don't use the
support module for trinidad, the std. behavior of these frameworks
On Wed, Jul 21, 2010 at 2:51 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi,
an optional trinidad-support module for codi, orchestra,... could use the
special events of trinidad. - these trinidad-support modules would have a
dependency to trinidad (and not the other way round). if
imo we should analyze which modules would make sense as stand-alone modules.
if there are 2+ of them, we should really think about such a modularization.
we might get new users who just use some of the stand-alone modules instead
of using something completely different (e.g. because they don't
On Wed, Jul 21, 2010 at 3:32 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
imo we should analyze which modules would make sense as stand-alone modules.
if there are 2+ of them, we should really think about such a modularization.
we might get new users who just use some of the
On Jul 20, 2010, at 7:52 PM, Gerhard Petracek wrote:
hi blake,
@events:
libs like codi might benefit from such additional events. we could think
about a trinidad-support module.
Sure
@trinidad window map:
i'm still not convinced. i would use a scope provided by libs like orchestra,
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.
@stand-alone trinidad window map:
do you mean there are some
-1 for having a duplicate functionality.
+1 for using CODI for the @WidnowScoped.
On Wed, Jul 21, 2010 at 8:05 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi blake,
@trinidad window map cdi:
we are just interested in some special events like a page-refresh
(triggered by the
IMHO, Having a duplicate functionality implemented in both CODI and Trinidad
is *not* a motivating thing for the users to upgrade the current working
Trinidad version BUT it will be a painful thing to maintain on both
projects. And for myself as an Apache MyFaces user, It is nice to see
projects
Hazem,
Where is the duplication of functionality? We are talking about an api. As
for the implementation, we can make it pluggable, though in fact, it already
is. If someone wants a WindowManager implementation that uses the Orchestra
scheme for identifying windows, they can do so.
--
Hazem,
I'm still not sure what part you think Trinidad and CODI are duplicating?
Trinidad defines a WindowManager and Window objects and contracts for their
behavior. A WindowManager implementation may have interesting code for
identifying windows and defining the lifecycle. CODI has
Blake,
What is the complexity of moving this functionality to CODI as a Trinidad
extensions on the CODI land?
On Wed, Jul 21, 2010 at 10:37 PM, Blake Sullivan
blake.sulli...@oracle.comwrote:
Hazem,
I'm still not sure what part you think Trinidad and CODI are duplicating?
Trinidad defines a
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
imo we don't really need to move it. it would be enough to introduce events
which get triggered by trinidad.
in a trinidad support module we could process these special events and
trigger the right parts of codi.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting,
+1
On Wed, Jul 21, 2010 at 11:09 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
imo we don't really need to move it. it would be enough to introduce events
which get triggered by trinidad.
in a trinidad support module we could process these special events and
trigger the right parts
+1
On Wed, Jul 21, 2010 at 11:00 PM, Gerhard Petracek
gerhard.petra...@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
On Jul 21, 2010 9:29 PM, Blake Sullivan blake.sulli...@oracle.com
wrote:
Hazem,
Where is the duplication of functionality? We are talking about an api. As
for the implementation, we can make it pluggable, though in fact, it already
is.
I don't understand this too.
If someone wants a
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
Hazem
On Wed, Jul 21, 2010 at 9:27 PM, Hazem Saleh haz...@apache.org wrote:
IMHO, Having a duplicate functionality implemented in both CODI and Trinidad
is *not* a motivating thing for the users to upgrade the current working
Trinidad version
why? So if Trinidad adds a new dependency for just
Hazem,
On Wed, Jul 21, 2010 at 9:57 PM, Hazem Saleh haz...@apache.org wrote:
Blake,
What is the complexity of moving this functionality to CODI as a Trinidad
extensions on the CODI land?
why do we have to introduce a new set of dependency, to just increase
an existing feature?
IMO it's
On Wed, Jul 21, 2010 at 10:00 PM, Gerhard Petracek
gerhard.petra...@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
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
On Wed, Jul 21, 2010 at 10:09 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
imo we don't really need to move it.
Thank you! :)
it would be enough to introduce events
which get triggered by trinidad.
in a trinidad support module we could process these special events and
trigger the
But still it is stupid to now stick in CDI and replace our
pageFlowScope (exists since every) and overhaul our Window/Event
system with it.
I said before that we can have modules for that:
* CODI-Trinidad-PageFlow
* CODI-Trinidad-WindowManager
both could be sub-modules under an umbrella trinidad
hi matthias,
We are just polishing an exiting feature.
i know - the question was: do we really need such new features/apis?
imo it's time to move forward and use the right tools (again see [1]).
using such a map for trinidad internals is ok. but it feels like a
workaround if users start using
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
hi blake,
@events:
libs like codi might benefit from such additional events. we could think
about a trinidad-support 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
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
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
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
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
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.sulli...@oracle.com
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.
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
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.sulli...@oracle.com
We currently have scopes for:
Application
Session
PageFlow
View
I propose that we add a Map
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
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
46 matches
Mail list logo
