Hi Yishay,
2018-05-12 20:17 GMT+02:00 Yishay Weiss <yishayj...@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 <yishayj...@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.
