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 13:32:47 GMT
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 like to use
trinidad as a whole).

i'm fine with starting a new thread.

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 Matthias Wessendorf <matzew@apache.org>

> On Wed, Jul 21, 2010 at 2:51 PM, Gerhard Petracek
> <gerhard.petracek@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 users don't use
> the
> > support module for trinidad, the std. behavior of these frameworks would
> be
> > used as fallback.
>
> I am fine with that, in parallel. At least CODI sounds interesting (for
> me).
>
> > i'm not talking about one jar file.
> > internally we would have several modules (e.g. a stand-alone skinning
> > module).
> > -> we can release the fine grained modules as well as trinidad-api and
> > trinidad-impl.
> > (we would need special modules just for packaging trinidad-api and
> > trinidad-impl jar files via the shade plugin of maven.)
> > -> some users would use the fine grained modules and the rest continues
> to
> > use trinidad-api and trinidad-impl (like today).
>
> hrm, is that really needed?
> Not sure that there is a lot of benefit from it, beside the extra work...
> On other subprojects, like CODI itself, it does make sense, since it
> is more modular.
>
> heck, this is a different topic, let's discuss that on a different
> (->new) thread :)
>
> -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 Matthias Wessendorf <matzew@apache.org>
> >>
> >> On Wed, Jul 21, 2010 at 2:02 PM, Gerhard Petracek
> >> <gerhard.petracek@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 their application/s.)
> >> > furthermore, i agree with martin - most projects are using (or will
> use)
> >> > one
> >> > of the mentioned frameworks.
> >>
> >> a lot != most :)
> >>
> >> > the questions are:
> >> > who would use this feature?
> >> >  - new projects? i don't think so.
> >>
> >> possible..
> >>
> >> >  - existing projects?
> >>
> >> yes, why not?
> >>
> >> > would they upgrade to a new version of trinidad just for using this
> >> > feature?
> >>
> >> pretty soon, I hope end of July, there will be a new release
> (2.0.0-beta),
> >> since
> >> the JSF2 and also its (jsf2) ajax bridge is kinda stable, now
> >>
> >> > maybe it's the right time to discuss our plans for the future of
> >> > trinidad.
> >>
> >> I know that - at least my goal - is finishing on the JSF 2.0 uptake.
> >> not sure if I am too thrilled about forcing hard dependencies to
> >> CDI/Spring
> >>
> >> but I said before, that we could layout an *independent* API for
> something
> >> like window/event systems and let submodules implement with APIs they
> >> want,
> >> e.g. CDI or more heavy-weight: Spring
> >>
> >> > (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.)
> >>
> >> for runtime dependency its is trinidad-api and trinidad-impl;
> >> wanna pack that into one jar?
> >>
> >> > 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
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Matthias Wessendorf
> >>
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> sessions: http://www.slideshare.net/mwessendorf
> >> twitter: http://twitter.com/mwessendorf
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

Mime
View raw message