flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent <vinc...@after24.net>
Subject Re: [FlexJS] Some things still missing ni FlexJS
Date Wed, 11 Jan 2017 10:04:12 GMT
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 <aharui@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" <developerlfm@gmail.com> wrote:
>>
>>> +1
>>>
>>> 2017-01-10 14:09 GMT+00:00 Fréderic Cox <coxfrederic@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 <vincent@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.rovira@gmail.com im Auftrag von
>>>>>> Carlos Rovira" <carlos.rovira@gmail.com im Auftrag von
>>>>>> carlos.rovira@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.lists@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.dutz@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.
>>>>>>
>>>>>>
>>>>>
>>
>


Mime
View raw message