Hi Peter,
I was also thinking how to help Nicolas and other folks who came with
similar problems.
I believe such table should contains Flex Component/Royale
Component/Beads/Description -
Flex Component - Just name
Royale Component - Name/Names of the Views if there are some which doing
more
Bead
It's a good idea. Would definitely make a transition easier if I
could plan out over time. Being able to stage changes to migrate more
easily would be welcome.
-Mark K
On Fri, Sep 29, 2017 at 2:40 PM, Peter Ent wrote:
> Hi,
>
> I'm moving to discussion over to Royale, but still including users
IMO, we want to compare the Express and maybe MDL packages against Flex's
Spark and MX. Comparing Basic components will be too difficult because of
how configurable they are. And this might inspire us to create a
Migration component set that is better tuned to ease migration.
My 2 cents,
-Alex
Hmm..But I was in my mind something simple. If we just show the names -
without to much details - even Basic can landed onto that table. Once user
see names will be able to look himself into that.
Piotr
On Sat, Sep 30, 2017, 00:22 Alex Harui wrote:
> IMO, we want to compare the Express and mayb
x.apache.org>"
mailto:users@flex.apache.org>>,
"ngra...@idylog.com<mailto:ngra...@idylog.com>"
mailto:ngra...@idylog.com>>
Subject: Re: [Royale] Flex to FlexJS migration path
Hmm..But I was in my mind something simple. If we just show the names - without
to much deta
component). This should not be a big deal with
the help of one or two lines of comments.
Hope this helps,
Regards,
Nicolas Granon
> -Message d'origine-
> De : Alex Harui [mailto:aha...@adobe.com.INVALID]
> Envoyé : samedi 30 septembre 2017 07:56
> À : us...@royale.a
equivalent class (for conceptual
>reasons), the link (in "Implementation hints") should explain why, in the
>JS/HTML world, an implementation is useless/meaningless.
>
>Of course, there are situations where it is not really possible to map
>components one-to-one (maybe, for example, bec
alent class (for conceptual
>reasons), the link (in "Implementation hints") should explain why, in the
>JS/HTML world, an implementation is useless/meaningless.
>
>Of course, there are situations where it is not really possible to map
>components one-to-one (maybe, for example, because
FileReference,
>>Formatters,Remoting etc...), showing possible "holes" in JS
>>implementation.
>>
>>It probably should link to Flex Apache docs... it is more logical since
>>they contains at least the same information as Adobe docs and they are
>>supposed
ption...
>>>>>
>>>>> Maybe a "discussion" link (on each line) would be interesting : it
>>>>> could
>>>>> lead to a page where implementers and developers could share their
>>>>> experience on a component-by-compo
st FlexJS equivalent" because it would usually really be the
>>>>>> "closest equivalent".
>>>>>> The link to API reference documentation would allow to see how the
>>>>>> "express" version is constructed and all the implement
a FlexJS or a MDL implementation, implementation hints
> >>>>>> should
> >>>>>> be empty (?).
> >>>>>>
> >>>>>> I think this leads naturally to giving the "express" implementation
> >>>>>>as
> >>>&g
gt;>>>>> If there is a FlexJS implementation, it is not necessary to give a
>>>>>>>MDL
>>>>>>> implementation (?).
>>>>>>> If there is a FlexJS or a MDL implementation, implementation hints
>>>>>>> s
13 matches
Mail list logo
