flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlos.rov...@codeoscopic.com>
Subject Re: [FlexJS] Some things still missing ni FlexJS
Date Wed, 11 Jan 2017 11:16:45 GMT
Hi Vincent,

I think we don't have nothing yet like Parsely or Swiz. It's clear that we
need many things to be in the same relation as Flex SDK, but my point is to
isolate the problem, so if people want to change, at least make him to
create a completely new interface that affects only to the client, so the
new client has the AMF hooks to connect in the same way as the old Flex
client.

If we tell people that they need to change the server layer, then the
boundaries are greater and many people will even think about it.

We could control in some way the needs of Swiz/Parsely, (and the others)
and start something from scratch that start to pull from our servers and
make an easy transition, without much pain and with time to a new FlexJS
client.



2017-01-11 11:04 GMT+01:00 Vincent <vincent@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 <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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>
>>
>


-- 

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message