I think parsley and similar should be able to run in FlexJS as they don’t rely
on any UI stuff and as far as I understood it, the concepts they are based on
should work with FlexJS. Haven’t tried that though ;-)
Chris
Am 11.01.17, 11:04 schrieb "Vincent" <vinc...@after24.net>:
Hi Carlos,
I agree with you. AMF support is essential for us to start thinking
porting our Flex apps to FlexJS.
I use MVC architecture with the support of Parsley 3 for :
- Dependency Injection
- Messaging
- Managed command (synchronous and asynchronous)
Is there an equivalent of this tools in the current version of FlexJS ?
Cheers.
Vincent.
Le 11/01/2017 à 10:43, Carlos Rovira a écrit :
> Hi Alex,
>
> I think many people in this thread are saying "No, we'll not go to
> production without AMF and basic module support". IMHO, it would be very
> difficult to say we have 1.0 without that, since AMF/RemoteObject was in
> almost 99% of old Flex SDK, with some HTTPServices and almost no
> WebServices (I mean the MXML object).
>
> As well, for a basic experiment, people could go without modules, but for
a
> producction App, a basic load of modules is needed.
>
> Then, i18n, Routing, Unit and Functionality testing and so on should come,
> but for me (If I must to choose) that could come after 1.0
>
> For example, in my own company, without AMF and Modules I don't have
enough
> to put FlexJS over React to ask people to use it over the other... (and I
> know that we'll find many other little things we need in the road)
>
> Just my 2ctns
>
>
> 2017-01-10 18:11 GMT+01:00 Alex Harui <aha...@adobe.com>:
>
>> In my mind, there is little doubt that someone will someday implement AMF
>> and not-unloadable modules. The question is when? IMO, as soon as
>> someone can tell us they've gone to production with the code we have, I'm
>> willing to call that 1.0, and the people who wrote that app probably
>> migrated a single SWF, single-language, XML or REST app. Regular Flex
>> grew just fine and it didn’t support modules in 1.0.
>>
>> For sure, as we add modules, AMF, I18N, we'll gain more customers, but I
>> am hesitant to say these are all 1.0 required features.
>>
>> Thoughts?
>> -Alex
>>
>> On 1/10/17, 6:28 AM, "Dev LFM" <developer...@gmail.com> wrote:
>>
>>> +1
>>>
>>> 2017-01-10 14:09 GMT+00:00 Fréderic Cox <coxfrede...@gmail.com>:
>>>
>>>> AMF is also essential for us to take FlexJS serious as a replacement to
>>>> Flex
>>>>
>>>> On Tue, Jan 10, 2017 at 2:41 PM, Vincent <vinc...@after24.net> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Same points than Christopher : AMF and modules.
>>>>> The first is essential for us.
>>>>>
>>>>> Vincent.
>>>>>
>>>>>
>>>>>
>>>>> Le 10/01/2017 à 13:07, Christofer Dutz a écrit :
>>>>>
>>>>>> +1 for the AMF and +1 for not-unloadable modules.
>>>>>>
>>>>>> I see it the same way as Carlos. At the moment I see FlexJS as an
>>>>>> opportunity for companies to get out of the dilemma of being stuck
>>>> in a
>>>>>> dead end with their existing Flex applications.
>>>>>> Supporting things like modules and AMF will ease the migration costs
>>>>>> dramatically. Even if AMF might be a touch slower than JSON I still
>>>> think
>>>>>> it’s worth being supported.
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>> Am 10.01.17, 12:14 schrieb "carlos.rov...@gmail.com im Auftrag von
>>>>>> Carlos Rovira" <carlos.rov...@gmail.com im Auftrag von
>>>>>> carlos.rov...@codeoscopic.com>:
>>>>>>
>>>>>> "IMO, this has two halves: non-unloadable modules is
relatively
>>>>>> straight
>>>>>> forward to do. Unloadable modules will be a ton of work.
IIRC,
>>>>>> Flex 1.0
>>>>>> and I think even Flex 2.x grew its customer base without
>>>> unloadable
>>>>>> modules."
>>>>>> If non-unloadable modules is easy to implement, I think it
>>>>>> should go ASAP.
>>>>>> Then we could left unloadable modules por the future...
>>>>>> For me, AMF is a must, since many companies are using it,
>>>> and
>>>> I
>>>>>> expect many
>>>>>> of them switch from old Flex to FlexJS if it's as easy as
change
>>>>>> only the
>>>>>> frontend. Change server code means no easy way to change, so
>>>> stick
>>>>>> in old
>>>>>> code
>>>>>> Thanks
>>>>>> 2017-01-08 9:52 GMT+01:00 Harbs <
>>>>>> harbs.li...@gmail.com>:
>>>>>> > I agree that skinning is harder than it should be.
>>>>>> >
>>>>>> > For one thing: There’s too many attributes which are set
>>>> directly.
>>>>>> More
>>>>>> > extensive use of CSS would make skinning easier.
>>>>>> >
>>>>>> > On Jan 8, 2017, at 10:49 AM, Christofer Dutz <
>>>>>> christofer.d...@c-ware.de>
>>>>>> > wrote:
>>>>>> >
>>>>>> > > From my side I’m missing skinnable components. I really
>>>> loved
>>>>>> the way I
>>>>>> > could create applications with skinning.
>>>>>> >
>>>>>> >
>>>>>> --
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>
>>
>
