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
a FlexJS or a MDL implementation, implementation hints
> >>>>>> should
> >>>>>> be empty (?).
> >>>>>>
> >>>>>> I think this leads naturally to giving the "express" implementation
> >>>>>>as
> >>>&g
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
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
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
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
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
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
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
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
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
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
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
Hi,
I'm moving to discussion over to Royale, but still including users from
flex who have not yet subscribed to the new Royale email lists.
I was speaking with Alex earlier and we thought the idea of a comparison
table was a good one. I've been giving some thought to what this might
look like and
14 matches
Mail list logo
