royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlosrov...@apache.org>
Subject Re: [DISCUSS] Explanation of the changes
Date Sat, 12 May 2018 20:43:03 GMT
Hi Yishay,


2018-05-12 20:17 GMT+02:00 Yishay Weiss <yishayjobs@hotmail.com>:

> Hi Carlos,
>
> Thanks for your detailed post.
>
> I don’t have time right now to address all of the points you raised, but
> what you wrote in the following extract strikes me as inaccurate.
>
> >For example Jewel Slider is based on input range, while Basic Slider is
> >build with two buttons. So even ISlider interfaces are different in Basic
> >than in Jewel.
> >So key point here: final implementations should not depend one from
> another
> >since any changes in the code of the parent will affect the children.
>
> Basic Slider does not depend on Button, SliderView does.


You're right I want to talk about SliderView instead of Slider. And if you
take a look is still just a copy, but it must change as I get time to
reflect the actual contract (this is one of the classes could other thing I
copied just for copy, but now is just a place holder that will be very
different to what we have in Basic. In SWF I think it should still be two
buttons, but in HTML the way to go is input range without doubt, is like
all modern framework (or not so modern) does.


> Why not just implement a different SliderView and extend Slider as is?


There's a SliderView implementation in Jewel, that makes the "fill" effect,
and other visual eye candy things like that. But if you compare both Slider
files (Basic and Jewel) you'll see that there's so much differences and are
very different final implementations. Maybe that's the point, final/leaf
implementations are mostly final, and I think force an inheritance is
doable, but most of time difficult. And what about is some Basic changes
break Jewel? I must say that this component in concrete even in MDL is
extending from UIBase, since I couldn't make it match with Basic Slider


> Conversely, if you think Slider should not have a view (I think it was
> designed that way for IE compatibility) why not fix it in Basic?


Fix in Basic means change it mostly to what we have in MDL and Jewel, but
think the noise generated each time we try to change something in
Basic...it generates lots of discussion and problems. To make that happen I
must to include the time to discuss over days, and that process each time
makes me search things to work around it. If I break Harbs App, or I change
how things are done until now...what I'm learning from the actual
experience is that is better to avoid that kind of conflicts if possible,
since people don't want to adapt to new things, although means less
coupling like in this case.


> Also, will swf be supported?


Yes! although the focus now is HTML (since is the most needed and would be
sufficient for many people, or people to adopt Royale), I'm trying to left
"placeholders" for SWF, but I'm not looking now how things look actually.
There's still many controls and components to add to Jewel to make it
really usable in a production application.


> If so, how will it be different from the Basic implementation?
>
>
Basic implementation is now looking raw (since is Basic).
Jewel will be very different, will start from a copy of Basic, but then
will change slowly to look that HTML version. That's at least my plan.



> I’m concerned that breaking dependencies from Basic is a challenge on the
> original design goals of Royale.


But if you use Basic, things are still the same, and people that is using
Basic, can still doing exactly the same. The challenge is already solved.
Or at least all examples are compiling and working as always (I opened all
of them to try it).

That a new effort (Jewel) can have challenges, is up to me that are the
only one investing time in make it production ready.
And I'm finding that in the new scenario things are far more easy than when
I was having to deal with all the unwanted things coming from Basic that
generated lots of discussion in MDL and Jewel through the years.


> As I understand it, these design goals include being platform agnostic,
> supporting old browsers, and using composition (view as a bead) as a means
> of specializing classes.


Exactly the same. You can see Jewel as a new version of Basic if you like.
Both do the same, but in Jewel I'm ensuring all things works and look
pretty. This makes me think one more good point. What when we want to make
Royale 2.0 some years in the future and we want to redo Basic? (like Flex
2, 3, 4...mx, then spark...I think you get it ;)), don't should be more
easy to do the same I'm doing in Jewel? Make a side project library that
don't depend on Basic and make it grow in parallel? or you want to still be
tied to the need to have Basic?


> If you don’t believe these are valid goals that’s fair enough, but I think
> it should be stated clearly. Maybe Basic needs fixing.
>

It's clear that we are in 0.9.3 and Basic has still various deficiencies,
mixed packages, but we are all very busy to do a major refactor now (IMHO),
so I did this refactor as a first point, I think divide and win strategy
here is good, since this first step give us a lot. Then from the
experience, don't know If I (at least) should propose more changes...even
I'm considering leave this project due to all the issues at community level
I'm living this days, when invest so many hours a day almost all days,
don't expect this kind of reaction...so mostly all depends on how this
discussion and vote will resolve.

Yishay, many thanks for your thoughts. Think very positive. Hope you have
the time to review all this more and give your personal thoughts.



>
> Yishay
>
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira


2018-05-12 20:17 GMT+02:00 Yishay Weiss <yishayjobs@hotmail.com>:

> Hi Carlos,
>
> Thanks for your detailed post.
>
> I don’t have time right now to address all of the points you raised, but
> what you wrote in the following extract strikes me as inaccurate.
>
> >For example Jewel Slider is based on input range, while Basic Slider is
> >build with two buttons. So even ISlider interfaces are different in Basic
> >than in Jewel.
> >So key point here: final implementations should not depend one from
> another
> >since any changes in the code of the parent will affect the children.
>
> Basic Slider does not depend on Button, SliderView does. Why not just
> implement a different SliderView and extend Slider as is? Conversely, if
> you think Slider should not have a view (I think it was designed that way
> for IE compatibility) why not fix it in Basic? Also, will swf be supported?
> If so, how will it be different from the Basic implementation?
>
> I’m concerned that breaking dependencies from Basic is a challenge on the
> original design goals of Royale. As I understand it, these design goals
> include being platform agnostic, supporting old browsers, and using
> composition (view as a bead) as a means of specializing classes. If you
> don’t believe these are valid goals that’s fair enough, but I think it
> should be stated clearly. Maybe Basic needs fixing.
>
> Yishay
>
>
>


-- 

<http://www.codeoscopic.com>

Carlos Rovira

Director General

M: +34 607 22 60 05

http://www.codeoscopic.com


Conócenos en 1 minuto! <https://avant2.es/#video>


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