Can you be more verbose on your concrete case ?
What do you mean by a tag ?
Would it be marked in the documentation (like Java and annotations AFAIK ) ?
Regards
2008/2/7, Philippe Poulard <[EMAIL PROTECTED]>:
>
> Stéphane ERARD a écrit :
> > Hi,
> >
> > On which side would you like to use Reflection ?
> >
> > On client-side ?
>
> Yes.
>
> I don't know if qooxdoo have reflection capabilities,
> > but if it has, well, why not =)
>
> I don't neither know if it's possible in Javascript and Qooxdoo.
>
> > Anyway, if we use Reflection, this is for some means, and these means
> > then should be abstracted to make working classes cleaner (just things
> > needed by abstraction to make things work).
>
> Concrete case : map a tag to a class, the class name is derived from the
> tag name, its attributes are arguments
>
> >
> > That said, if we have for some thing to be done, an abstract class and
> > then for each cases of the abstract thing some special classes (or not),
> > then we would have the generality thing done by abstract (using data
> > only) and for special cases the behavior redefined by the extending
> > class (which would use the given data of course- abstract-).
> > Anyway, this point out that special things must be defined : the class
> > must exists.
> >
> > So, at some point, if we want to use reflection (if exists), then datas
> > must include class name if they need special treatment, or something
> > like a marker to say "No I'm not a generic data, handle me this way" >
>
> With XML datas it is straightforward : just use a namespace for that
> purpose
>
> > this is somewhat Strategy pattern ?
> >
> > At least, I prefer the "generate js code on server-side" solution. If
> > it's during build process, sounds better.
> >
> > To be clear : on production, I would not use dynamically generated
> > components (for both client and server side) because....people isn't a
> > programmer =)
> > If we mean to use this to help us generate production code, and modify
> > them somewhat later, then this sounds good to me =)
> > Anyway, there are other means to do this : openArchitectureWare (meta
> > programming).
> >
> >
> > Well, this is my point of view. Not to be THE truth =)
> >
> > Regards
> >
> >
> >
> > 2008/2/7, Philippe Poulard <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>>:
> >
> > Stéphane ERARD a écrit :
> > > Hi,
> > >
> > > I just would like to say my thoughts:
> > > on large, big applications (supposing qooxdoo is meant to build
> > strong,
> > > big applications),
> > > we developers need to be able to specialize anything needed when
> > needed.
> >
> > ...for the most demanding :)
> >
> > > If we build things accordingly to datas, and only datas, in
> > production I
> > > believe this is bad idea because we can't specialize, or we would
> > need a
> > > switch statement somewhere in the code to manage special cases.
> >
> > So far, I agree
> >
> > Uh !
> > > I prefer having lot of classes but this would allow me to
> specialize
> > > when needed. Just having to extend some class somewhere, then it
> is
> > > 'static' in some way (behavior is written in a class, even if
> > abstract).
> >
> > What about 'reflection' capabilities (that brings dynamicity) ?
> >
> > > This is bacic usage of abstraction in oo I believe.
> > >
> > > Hope I'm clear enought.
> > >
> > > What do you think of this ?
> >
> > --
> > Cordialement,
> >
> > ///
> > (. .)
> > --------ooO--(_)--Ooo--------
> > | Philippe Poulard |
> > -----------------------------
> > http://reflex.gforge.inria.fr/
> > Have the RefleX !
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > qooxdoo-devel mailing list
> > [email protected]
> > <mailto:[email protected]>
> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> >
> >
> >
> >
> > --
> > Before Printing, Think about Your Environmental Responsibility!
> > Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale!
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > qooxdoo-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
> --
> Cordialement,
>
> ///
> (. .)
> --------ooO--(_)--Ooo--------
> | Philippe Poulard |
> -----------------------------
> http://reflex.gforge.inria.fr/
> Have the RefleX !
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
--
Before Printing, Think about Your Environmental Responsibility!
Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale!
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
