You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Carlos Rovira <ca...@apache.org> on 2017/02/09 09:11:14 UTC
[FlexJS] Injection library
Hi,
I'm trying to craft an Injection library for FlexJS based on Flex 4 Swiz
Framework.
So in order to do this, I would need some support. First is to know more
about "ApplicationDomain" in FlexJS
does we have something similar in FlexJS?
Thanks
--
Carlos Rovira
http://about.me/carlosrovira
Re: [FlexJS] Injection library
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Piotr,
I always thought Swiz was more easy, simple, confortable and also very
powerful :)
2017-02-09 20:12 GMT+01:00 piotrz <pi...@gmail.com>:
> Carlos,
>
> Out of curious you did choose Swiz as an example cause you know this
> framework ? Why not Parsley which seems to be more popular back in the day.
>
> Piotr
>
>
>
>
>
> -----
> Apache Flex PMC
> piotrzarzycki21@gmail.com
> --
> View this message in context: http://apache-flex-
> development.2333347.n4.nabble.com/FlexJS-Injection-library-
> tp59177p59194.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
--
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.
Re: [FlexJS] Injection library
Posted by piotrz <pi...@gmail.com>.
Carlos,
Out of curious you did choose Swiz as an example cause you know this
framework ? Why not Parsley which seems to be more popular back in the day.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Injection-library-tp59177p59194.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Injection library
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Alex, while I understand your proposal I will prefer to have not only
that mechanism but
as well falcon to know more about metadata and evolve to make more things.
Having best of both worlds looks more "flex"-ible to me :)
2017-02-13 17:43 GMT+01:00 Alex Harui <ah...@adobe.com>:
>
>
> On 2/13/17, 2:56 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
> wrote:
>
> >Hi Alex,
> >
> >DI frameworks has many more things. For example If I configure a model
> >bean
> >of type ProductModel and give it an id of "productModel", in each class I
> >declare a
> >var productModel:ProductModel, the framework will inject it.
> >
> >With bead/strands we would need to make that in all declarations.
> >As well, beads/strands seems to be very prepared for MXML but not to be
> >tweaked in AS3
>
> IMO, that isn't true. You could have a single application level bead that
> watches for objects being added to the DOM.
> But yes, I am proposing that MXML with beads is a structured way of
> "annotating" objects.
>
> >
> >Metadata as well is something very powerful and I expect we could get more
> >of this in the future
> >both in compiler and language (like Generics) or in a DI framework
> >
> >IMHO, we should not restrict o simplify this. We should embrace all this
> >things DI, Annotations/Metadata,
> >beads/strands,... since each one has its own points and will make FlexJS
> >something ahead the rest
>
> Well, we have Metadata support already. I'm just pointing out that in
> many ways with regular Flex, Metadata was the only option for extending
> objects at runtime. In FlexJS, with beads, I think we have another more
> structured way of extending objects at runtime, so brand-new DI frameworks
> should consider that. Just like we say that AS is better than JS because
> it is structured, maybe beads for DI is better than Metadata also because
> it is structured. I encourage you, if you are going to write a
> next-generation DI framework, to think out-of-the-box and not just re-use
> the old techniques without considering the new ones. I remember seeing
> some Parsely code and watching how it waited for creationComplete before
> applying its changes to the objects which cause a full re-validation of
> the DOM and thinking that for FlexJS, we could make DI-friendly component
> sets that have different lifecycle events that allow injection without
> forcing a full second-pass. Things can be much better when you can design
> them in vs having to patch them in from the outside.
>
> -Alex
>
>
--
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.
Re: [FlexJS] Injection library
Posted by Alex Harui <ah...@adobe.com>.
On 2/13/17, 2:56 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com> wrote:
>Hi Alex,
>
>DI frameworks has many more things. For example If I configure a model
>bean
>of type ProductModel and give it an id of "productModel", in each class I
>declare a
>var productModel:ProductModel, the framework will inject it.
>
>With bead/strands we would need to make that in all declarations.
>As well, beads/strands seems to be very prepared for MXML but not to be
>tweaked in AS3
IMO, that isn't true. You could have a single application level bead that
watches for objects being added to the DOM.
But yes, I am proposing that MXML with beads is a structured way of
"annotating" objects.
>
>Metadata as well is something very powerful and I expect we could get more
>of this in the future
>both in compiler and language (like Generics) or in a DI framework
>
>IMHO, we should not restrict o simplify this. We should embrace all this
>things DI, Annotations/Metadata,
>beads/strands,... since each one has its own points and will make FlexJS
>something ahead the rest
Well, we have Metadata support already. I'm just pointing out that in
many ways with regular Flex, Metadata was the only option for extending
objects at runtime. In FlexJS, with beads, I think we have another more
structured way of extending objects at runtime, so brand-new DI frameworks
should consider that. Just like we say that AS is better than JS because
it is structured, maybe beads for DI is better than Metadata also because
it is structured. I encourage you, if you are going to write a
next-generation DI framework, to think out-of-the-box and not just re-use
the old techniques without considering the new ones. I remember seeing
some Parsely code and watching how it waited for creationComplete before
applying its changes to the objects which cause a full re-validation of
the DOM and thinking that for FlexJS, we could make DI-friendly component
sets that have different lifecycle events that allow injection without
forcing a full second-pass. Things can be much better when you can design
them in vs having to patch them in from the outside.
-Alex
Re: [FlexJS] Injection library
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Alex,
DI frameworks has many more things. For example If I configure a model bean
of type ProductModel and give it an id of "productModel", in each class I
declare a
var productModel:ProductModel, the framework will inject it.
With bead/strands we would need to make that in all declarations.
As well, beads/strands seems to be very prepared for MXML but not to be
tweaked in AS3
Other things that never came to Swiz, or other similar frameworks, and I'd
love to see here:
For example if you want to affect various objects of a type a inject some
behavior
(imagine some logging behaviour)
Metadata as well is something very powerful and I expect we could get more
of this in the future
both in compiler and language (like Generics) or in a DI framework
Other thinks I like it is validation based on metadata (like people at
GraniteDS did)
I always thought that old Flex validation was not covering all things, and
I expect to have
validation behaviour attached to the VO, POJO or DTO variable.
IMHO, we should not restrict o simplify this. We should embrace all this
things DI, Annotations/Metadata,
beads/strands,... since each one has its own points and will make FlexJS
something ahead the rest
2017-02-10 20:05 GMT+01:00 Alex Harui <ah...@adobe.com>:
>
>
> On 2/10/17, 4:22 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
> wrote:
>
> >I check PureMVC many years ago, and liked it so much. But For me Swiz (or
> >Parsely) has sometihing I can't pass without... Dependency Injection. For
> >me annotations or metadata is a must, not only in this kind of micro
> >architectures, but a must in other type of code.
>
> I've never used DI frameworks so I may be completely off-base, but IMO, I
> wonder if metadata is the best way to do things like DI. I remember
> discussions among my Adobe colleagues that metadata is becoming a language
> unto itself. There really is no checking on Metadata by the compiler or
> runtime, so it is essentially as unstructured as JavaScript.
>
> One of the things that beads/strands allows is the "injection" of
> functionality in a way that is checked by the compiler. If you mis-type
> the name of the bead, the code-hinting and/or compiler will catch you.
> You can use CSS to externalize what beads get applied and the compiler
> will catch you if you mistype what goes in the ClassReference.
>
> Furthermore, I believe it may be faster for the DI engine to examine the
> strand instead of examine the metadata.
>
> So, while it would be great to lower the barriers to migration by porting
> the various Application-level Frameworks from Flex, if you are going to
> write a new DI subsystem, should you consider doing it in a more
> structured way?
>
> Thoughts?
> -Alex
>
>
--
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.
Re: [FlexJS] Injection library
Posted by Alex Harui <ah...@adobe.com>.
On 2/10/17, 4:22 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com> wrote:
>I check PureMVC many years ago, and liked it so much. But For me Swiz (or
>Parsely) has sometihing I can't pass without... Dependency Injection. For
>me annotations or metadata is a must, not only in this kind of micro
>architectures, but a must in other type of code.
I've never used DI frameworks so I may be completely off-base, but IMO, I
wonder if metadata is the best way to do things like DI. I remember
discussions among my Adobe colleagues that metadata is becoming a language
unto itself. There really is no checking on Metadata by the compiler or
runtime, so it is essentially as unstructured as JavaScript.
One of the things that beads/strands allows is the "injection" of
functionality in a way that is checked by the compiler. If you mis-type
the name of the bead, the code-hinting and/or compiler will catch you.
You can use CSS to externalize what beads get applied and the compiler
will catch you if you mistype what goes in the ClassReference.
Furthermore, I believe it may be faster for the DI engine to examine the
strand instead of examine the metadata.
So, while it would be great to lower the barriers to migration by porting
the various Application-level Frameworks from Flex, if you are going to
write a new DI subsystem, should you consider doing it in a more
structured way?
Thoughts?
-Alex
Re: [FlexJS] Injection library
Posted by OK <po...@olafkrueger.net>.
>If you want injection and PureMVC maybe you should check fabrication [1]
This probably also need some refactoring to remove the mx/flash
depenencies...
Olaf
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Injection-library-tp59177p59217.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Injection library
Posted by piotrz <pi...@gmail.com>.
Carlos,
If you want injection and PureMVC maybe you should check fabrication [1]
[1] https://github.com/rafalszemraj/fabrication
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Injection-library-tp59177p59216.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Injection library
Posted by Carlos Rovira <ca...@codeoscopic.com>.
I check PureMVC many years ago, and liked it so much. But For me Swiz (or
Parsely) has sometihing I can't pass without... Dependency Injection. For
me annotations or metadata is a must, not only in this kind of micro
architectures, but a must in other type of code. For example validation
with annotation like in GraniteDS, was great as well...that makes
development easier and enjoyable. Hope we could bring all this to FlexJS
since is what could make the difference
2017-02-10 11:45 GMT+01:00 Dev LFM <de...@gmail.com>:
> I like Swiz too.. all the others need more code to get things started, but
> I believe it's really tight to flex, if other mvc frameworks are easier to
> port, I think you should go for the fastest way..
>
> 2017-02-10 8:57 GMT+00:00 OK <po...@olafkrueger.net>:
>
> > Hi ,
> > I don't want to start a framework discussion here but I'm loving PureMVC
> > and
> > would like to describe my point of view:
> >
> > I'm using PureMVC for years and these days it turns out that is more
> > powerful than ever for me.
> >
> > I remember a lot of discussions regarding AS3 framework benchmarks and
> > their
> > particular features a few years ago. And I also remember that Cliff Hall
> > (the author of PureMVC) was never tired to explain why PureMVC is like it
> > is
> > and why it doesn't implement the "hottest shit" [1].
> >
> > Years later I understand Cliffs ideas behind PureMVC more and more. Today
> > we
> > can just grab a copy of PureMVC and compile it to JavaScript... it works
> > with FlexJS out of the box!
> >
> > The other big advantage of PureMVC is that it was ported to nearly any
> > relevant programming language.
> > And if there's no port for your favorite language available you've a fair
> > chance to implement it by yourself cause PureMVC consist of just a few
> > classes and interfaces.
> > At the end this means that you've a faire chance to port your complete
> > business logic of of your valuable apps to any other programming
> language.
> > Maybe this will be never happen but to know that it would be possible
> > calmed
> > down ;-)
> >
> > Thanks,
> > Olaf
> >
> >
> > [1] Quote of http://puremvc.org/
> > While the "release early, release often" development philosophy can help
> a
> > team learn what their product should do, if that product is a framework,
> > adopters often tire of trying to hit a moving target. With PureMVC, we
> > nailed down the scope early on, fixed the bugs, and let it be.
> >
> >
> >
> >
> >
> >
> >
> > --
> > View this message in context: http://apache-flex-
> > development.2333347.n4.nabble.com/FlexJS-Injection-library-
> > tp59177p59212.html
> > Sent from the Apache Flex Development mailing list archive at Nabble.com.
> >
>
--
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.
Re: [FlexJS] Injection library
Posted by Dev LFM <de...@gmail.com>.
I like Swiz too.. all the others need more code to get things started, but
I believe it's really tight to flex, if other mvc frameworks are easier to
port, I think you should go for the fastest way..
2017-02-10 8:57 GMT+00:00 OK <po...@olafkrueger.net>:
> Hi ,
> I don't want to start a framework discussion here but I'm loving PureMVC
> and
> would like to describe my point of view:
>
> I'm using PureMVC for years and these days it turns out that is more
> powerful than ever for me.
>
> I remember a lot of discussions regarding AS3 framework benchmarks and
> their
> particular features a few years ago. And I also remember that Cliff Hall
> (the author of PureMVC) was never tired to explain why PureMVC is like it
> is
> and why it doesn't implement the "hottest shit" [1].
>
> Years later I understand Cliffs ideas behind PureMVC more and more. Today
> we
> can just grab a copy of PureMVC and compile it to JavaScript... it works
> with FlexJS out of the box!
>
> The other big advantage of PureMVC is that it was ported to nearly any
> relevant programming language.
> And if there's no port for your favorite language available you've a fair
> chance to implement it by yourself cause PureMVC consist of just a few
> classes and interfaces.
> At the end this means that you've a faire chance to port your complete
> business logic of of your valuable apps to any other programming language.
> Maybe this will be never happen but to know that it would be possible
> calmed
> down ;-)
>
> Thanks,
> Olaf
>
>
> [1] Quote of http://puremvc.org/
> While the "release early, release often" development philosophy can help a
> team learn what their product should do, if that product is a framework,
> adopters often tire of trying to hit a moving target. With PureMVC, we
> nailed down the scope early on, fixed the bugs, and let it be.
>
>
>
>
>
>
>
> --
> View this message in context: http://apache-flex-
> development.2333347.n4.nabble.com/FlexJS-Injection-library-
> tp59177p59212.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
Re: [FlexJS] Injection library
Posted by OK <po...@olafkrueger.net>.
Hi ,
I don't want to start a framework discussion here but I'm loving PureMVC and
would like to describe my point of view:
I'm using PureMVC for years and these days it turns out that is more
powerful than ever for me.
I remember a lot of discussions regarding AS3 framework benchmarks and their
particular features a few years ago. And I also remember that Cliff Hall
(the author of PureMVC) was never tired to explain why PureMVC is like it is
and why it doesn't implement the "hottest shit" [1].
Years later I understand Cliffs ideas behind PureMVC more and more. Today we
can just grab a copy of PureMVC and compile it to JavaScript... it works
with FlexJS out of the box!
The other big advantage of PureMVC is that it was ported to nearly any
relevant programming language.
And if there's no port for your favorite language available you've a fair
chance to implement it by yourself cause PureMVC consist of just a few
classes and interfaces.
At the end this means that you've a faire chance to port your complete
business logic of of your valuable apps to any other programming language.
Maybe this will be never happen but to know that it would be possible calmed
down ;-)
Thanks,
Olaf
[1] Quote of http://puremvc.org/
While the "release early, release often" development philosophy can help a
team learn what their product should do, if that product is a framework,
adopters often tire of trying to hit a moving target. With PureMVC, we
nailed down the scope early on, fixed the bugs, and let it be.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Injection-library-tp59177p59212.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Injection library
Posted by Josh Tynjala <jo...@gmail.com>.
I ported Robotlegs to Starling a while back, and that conversion wasn't too
complicated. That might be another good candidate for FlexJS.
- Josh
On Thu, Feb 9, 2017 at 4:01 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 2/9/17, 3:45 PM, "piotrz" <pi...@gmail.com> wrote:
>
> >Carlos,
> >
> >I was using Swiz, Parsley and PureMVC. If I would choose some integration
> >with FlexJS it would be definately PureMVC, cause It has pure AS3
> >implementation. If I would build some old Fashion Flex app -
> >mobile/desktop
> >- my pick up would be Parsley.
> >
> >But I looking forward to the results of your work.
>
> Really, I hope someone steps up and tries to port Swiz and Parsely. They
> might get lucky as folks did with PureMVC. I have not used any of these
> and don't have time to help on it myself, but it would lower the barrier
> to migration. It would be fun to see how much of AS3Commons would "just
> work" as well. But again, my plate is full.
>
> -Alex
>
>
Re: [FlexJS] Injection library
Posted by Alex Harui <ah...@adobe.com>.
On 2/9/17, 3:45 PM, "piotrz" <pi...@gmail.com> wrote:
>Carlos,
>
>I was using Swiz, Parsley and PureMVC. If I would choose some integration
>with FlexJS it would be definately PureMVC, cause It has pure AS3
>implementation. If I would build some old Fashion Flex app -
>mobile/desktop
>- my pick up would be Parsley.
>
>But I looking forward to the results of your work.
Really, I hope someone steps up and tries to port Swiz and Parsely. They
might get lucky as folks did with PureMVC. I have not used any of these
and don't have time to help on it myself, but it would lower the barrier
to migration. It would be fun to see how much of AS3Commons would "just
work" as well. But again, my plate is full.
-Alex
Re: [FlexJS] Injection library
Posted by piotrz <pi...@gmail.com>.
Carlos,
I was using Swiz, Parsley and PureMVC. If I would choose some integration
with FlexJS it would be definately PureMVC, cause It has pure AS3
implementation. If I would build some old Fashion Flex app - mobile/desktop
- my pick up would be Parsley.
But I looking forward to the results of your work.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Injection-library-tp59177p59206.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Injection library
Posted by Harbs <ha...@gmail.com>.
We used PureMVC which worked as-is with no modifications at all.
I think PureMVC is much simpler than Swiz though.
> On Feb 10, 2017, at 1:20 AM, Alex Harui <ah...@adobe.com> wrote:
>
> Hi Carlos,
>
> Are you sure you don't just want to try to port Swiz? I think
> Harbs/Yishay and maybe others got some other framework to port over. If
> you port, you know the untouched code paths are operational. If you start
> over you have to prove every line of code. And if you do port Swiz, that
> will attract a few migration candidates.
>
> Thanks,
> -Alex
>
> On 2/9/17, 1:52 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com> wrote:
>
>> Thanks Alex,
>>
>> I'll try to make things simple and bypass class domain stuff. If at the
>> end
>> I need it I'll check that. My approximation is get the most simple engine
>> working and then make progress from there.
>>
>> Thanks!
>>
>>
>> 2017-02-09 21:14 GMT+01:00 Alex Harui <ah...@adobe.com>:
>>
>>>
>>>
>>> On 2/9/17, 11:07 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>> Rovira"
>>> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
>>> wrote:
>>>
>>>> HI Alex,
>>>>
>>>> Swiz use ApplicaionDomain extensively. If we don't have yet and doesn't
>>>> have sense in FlexJS world I can try to remove it.
>>>
>>> What is it using ApplicationDomains for? IOW, if it is just as the
>>> wrapper for reflection APIs, it should be straight forward to emulate.
>>> Every single-swf application has only one ApplicationDomain. Even apps
>>> that only use RSLs have only one ApplicationDomain. I would assume Swiz
>>> worked fine for those? It is only when you get into unloadable modules
>>> or
>>> SWFLoaders that load sub-applications that you really need
>>> ApplicationDomains concept of domains of classes.
>>>
>>> When I was doing the spark "port", I created the following class in the
>>> Spark branch to emulate the main ApplicationDomain APIs
>>> frameworks/projects/MX/src/main/flex/flex/system/DefinitionManager.as
>>>
>>>
>>> Maybe it will help you. It wasn't been fully tested.
>>>
>>> -Alex
>>>
>>>
>>
>>
>> --
>>
>> Carlos Rovira
>> Director General
>> M: +34 607 22 60 05
>> http://www.codeoscopic.com
>> http://www.avant2.es
>>
>> Este mensaje se dirige exclusivamente a su destinatario y puede contener
>> información privilegiada o confidencial. Si ha recibido este mensaje por
>> error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
>> proceda a su destrucción.
>>
>> De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>> comunicamos
>> que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>> S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>> servicio o información solicitados, teniendo usted derecho de acceso,
>> rectificación, cancelación y oposición de sus datos dirigiéndose a
>> nuestras
>> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
>> necesaria.
>
Re: [FlexJS] Injection library
Posted by Alex Harui <ah...@adobe.com>.
Hi Carlos,
Are you sure you don't just want to try to port Swiz? I think
Harbs/Yishay and maybe others got some other framework to port over. If
you port, you know the untouched code paths are operational. If you start
over you have to prove every line of code. And if you do port Swiz, that
will attract a few migration candidates.
Thanks,
-Alex
On 2/9/17, 1:52 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com> wrote:
>Thanks Alex,
>
>I'll try to make things simple and bypass class domain stuff. If at the
>end
>I need it I'll check that. My approximation is get the most simple engine
>working and then make progress from there.
>
>Thanks!
>
>
>2017-02-09 21:14 GMT+01:00 Alex Harui <ah...@adobe.com>:
>
>>
>>
>> On 2/9/17, 11:07 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
>> wrote:
>>
>> >HI Alex,
>> >
>> >Swiz use ApplicaionDomain extensively. If we don't have yet and doesn't
>> >have sense in FlexJS world I can try to remove it.
>>
>> What is it using ApplicationDomains for? IOW, if it is just as the
>> wrapper for reflection APIs, it should be straight forward to emulate.
>> Every single-swf application has only one ApplicationDomain. Even apps
>> that only use RSLs have only one ApplicationDomain. I would assume Swiz
>> worked fine for those? It is only when you get into unloadable modules
>>or
>> SWFLoaders that load sub-applications that you really need
>> ApplicationDomains concept of domains of classes.
>>
>> When I was doing the spark "port", I created the following class in the
>> Spark branch to emulate the main ApplicationDomain APIs
>> frameworks/projects/MX/src/main/flex/flex/system/DefinitionManager.as
>>
>>
>> Maybe it will help you. It wasn't been fully tested.
>>
>> -Alex
>>
>>
>
>
>--
>
>Carlos Rovira
>Director General
>M: +34 607 22 60 05
>http://www.codeoscopic.com
>http://www.avant2.es
>
>Este mensaje se dirige exclusivamente a su destinatario y puede contener
>información privilegiada o confidencial. Si ha recibido este mensaje por
>error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
>proceda a su destrucción.
>
>De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>comunicamos
>que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>servicio o información solicitados, teniendo usted derecho de acceso,
>rectificación, cancelación y oposición de sus datos dirigiéndose a
>nuestras
>oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
>necesaria.
Re: [FlexJS] Injection library
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Thanks Alex,
I'll try to make things simple and bypass class domain stuff. If at the end
I need it I'll check that. My approximation is get the most simple engine
working and then make progress from there.
Thanks!
2017-02-09 21:14 GMT+01:00 Alex Harui <ah...@adobe.com>:
>
>
> On 2/9/17, 11:07 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
> wrote:
>
> >HI Alex,
> >
> >Swiz use ApplicaionDomain extensively. If we don't have yet and doesn't
> >have sense in FlexJS world I can try to remove it.
>
> What is it using ApplicationDomains for? IOW, if it is just as the
> wrapper for reflection APIs, it should be straight forward to emulate.
> Every single-swf application has only one ApplicationDomain. Even apps
> that only use RSLs have only one ApplicationDomain. I would assume Swiz
> worked fine for those? It is only when you get into unloadable modules or
> SWFLoaders that load sub-applications that you really need
> ApplicationDomains concept of domains of classes.
>
> When I was doing the spark "port", I created the following class in the
> Spark branch to emulate the main ApplicationDomain APIs
> frameworks/projects/MX/src/main/flex/flex/system/DefinitionManager.as
>
>
> Maybe it will help you. It wasn't been fully tested.
>
> -Alex
>
>
--
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.
Re: [FlexJS] Injection library
Posted by Alex Harui <ah...@adobe.com>.
On 2/9/17, 11:07 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com> wrote:
>HI Alex,
>
>Swiz use ApplicaionDomain extensively. If we don't have yet and doesn't
>have sense in FlexJS world I can try to remove it.
What is it using ApplicationDomains for? IOW, if it is just as the
wrapper for reflection APIs, it should be straight forward to emulate.
Every single-swf application has only one ApplicationDomain. Even apps
that only use RSLs have only one ApplicationDomain. I would assume Swiz
worked fine for those? It is only when you get into unloadable modules or
SWFLoaders that load sub-applications that you really need
ApplicationDomains concept of domains of classes.
When I was doing the spark "port", I created the following class in the
Spark branch to emulate the main ApplicationDomain APIs
frameworks/projects/MX/src/main/flex/flex/system/DefinitionManager.as
Maybe it will help you. It wasn't been fully tested.
-Alex
Re: [FlexJS] Injection library
Posted by Carlos Rovira <ca...@codeoscopic.com>.
HI Alex,
Swiz use ApplicaionDomain extensively. If we don't have yet and doesn't
have sense in FlexJS world I can try to remove it.
At last this wouldn't be Swiz at all, but new code that is based in the
Swiz principles. I think we could even rename it to other name. I was
thinking on "Struct", "Spash" or "Injezz" so we could refer to easily
I have to see what we have in Reflection.swc since Swiz uses flash
reflection classes, and I expect we have some port that I could use as
substitution. As well it has it's own reflection package that handles its
own set of needs.
Thanks
2017-02-09 16:59 GMT+01:00 Alex Harui <ah...@adobe.com>:
>
>
> On 2/9/17, 1:11 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >Hi,
> >
> >I'm trying to craft an Injection library for FlexJS based on Flex 4 Swiz
> >Framework.
> >
> >So in order to do this, I would need some support. First is to know more
> >about "ApplicationDomain" in FlexJS
> >
> >does we have something similar in FlexJS?
>
> Well, it depends...
>
> There is no ApplicationDomain construct where you can have separate
> bundles of classes that can be unloaded, and have one area of code using a
> different definition of a Class than another area of code.
>
> With a lot of work, we could probably handle separate bundles of classes,
> but I'm not sure we'll ever be able to handle having different areas of
> code use different definitions.
>
> Does Swiz actually use those features of ApplicationDomain, or is it just
> using the "Reflection" features like hasDefinition/getDefinition. The
> Reflection.swc has support for that today.
>
> HTH,
> -Alex
>
>
--
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.
Re: [FlexJS] Injection library
Posted by Alex Harui <ah...@adobe.com>.
On 2/9/17, 1:11 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>Hi,
>
>I'm trying to craft an Injection library for FlexJS based on Flex 4 Swiz
>Framework.
>
>So in order to do this, I would need some support. First is to know more
>about "ApplicationDomain" in FlexJS
>
>does we have something similar in FlexJS?
Well, it depends...
There is no ApplicationDomain construct where you can have separate
bundles of classes that can be unloaded, and have one area of code using a
different definition of a Class than another area of code.
With a lot of work, we could probably handle separate bundles of classes,
but I'm not sure we'll ever be able to handle having different areas of
code use different definitions.
Does Swiz actually use those features of ApplicationDomain, or is it just
using the "Reflection" features like hasDefinition/getDefinition. The
Reflection.swc has support for that today.
HTH,
-Alex