On Wed, Aug 29, 2012 at 12:19 PM, Michael A. Labriola < labri...@digitalprimates.net> wrote:
> >Can you please elaborate? > > >The point I was trying to make was that HTML5 language itself is not > designed to be extensible. Using Javascript does not really count (in this > >context) > > >As far as using the DOM, I assume you mean the Microdata format. This > results in non-standard HTML most of the time and is not supported across > browsers. And it deals more with extending data semantics and >not > functional extension. > > In flex, IMO, we worried too much about extension and not enough about > composition. I think that is besides the point. There is nothing in MXML that prevents composition. It is just that the current set of Flex components are built like that. We can fix that given time and effort. There is no need to structurally modify MXML to achieve this. Whereas with HTML(5) there is nothing in the standard that will let us do specialization (via inheritance or composition) I cannot dream up new elements and expect a browser to understand it out of the box. > So long as I have a good series of patterns (and the discipline to follow > them) then I can look at the HTML DOM elements as the Atoms of the universe > and assembly them with some bonds (JavaScript) to make an element. And then > in turn assemble those to make any application. > Right, we need Javascript to do this kind of extension to HTML. To do this in the Flex world would mean that we either * Bring in JS as a language we support in Flex or * Keep Flex as it is (i.e. Actionscript based) and have a AS to JS translation layer. The latter is a better approach because of various reasons ranging from JS not being a real OOP language, no package organization possible, etc (we all know why AS is better than JS) I think being able to code in MXML and Actionscript would be a key goal of this cross-compilation effort, right? Unless we want to fundamentally change what 'Flex' means. > So, the key is not trying to extend the Atom but trying to assemble it in > useful ways and allow those to be extended or recomposed. So far, I have > found few limitations of this approach and often times ended up much > happier. > > I definitely agree with you on this. But again, this requires Javascript to assemble things. My above points still hold good as well. > Mike > > Thanks, Om
