Thanks for that info on Jquery and Dojo. Do they have skinning models? How does it work?
More inline.. On 10/16/14, 11:29 AM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: >I understand that you want to use the default HTML elements as building >blocks. I think there are major problems with this approach. > >In essence, we have a very limited set of default HTML elements to start >with. If we want to compose our entire application with these, we will >quickly run into cases where we need more complex base components. Agreed, and in FlexJS today, we have already composed some higher-level components. There is a List that just wraps <select> and another one that supports item renderers that doesn’t use <select>. > >There are some scenarios where SVG is not good enough for us. For >example, >9-slice scaling. SVG does not support this flat out. Whereas, there is a >way to hack 9-slice skinning using SVG and ForeignObjects. But none of >the >drawing tools (Illustrator, Flash Pro or Incscape) support this hack. >I plan to interpret the 9-slice attributes (exported from AI, for example) >and draw the svg/foreignobject combinations on the JS side. On the flash >side, 9-slice skinning is supported built in. > >Also, loading SVG instead of drawing it using JS brings its own set of >challenges. I feel drawing SVG using JS is a better approach. Sounds reasonable. There doesn’t have to be one approach. Different component sets can implement different approaches. Question: How many apps need 9-slice and what will it cost to support it? In the FlexJS pay-as-you-go philosophy, there could be a component set that doesn’t support 9-slice if the net result is smaller downloads or better performance because the FXG is pre-compiled in SVG and not re-interpreted at runtime. > > >> >> But fundamentally, I think we now have the ability to specify just about >> every visual aspect of a FlexJS app as MXML plus some CSS, but I think >>the >> HTML Button might flicker, and not all MXML will work in all components >>in >> the JS side unless I’m wrong about the "closeable tab” scenario. Maybe >> that means there should be some other default Button in FlexJS and we >> should give up on the built-in HTML Button or maybe that’s good enough. >> > >Yes, IMHO, we should give up on the build-in HTML button. That is good >for >simple websites, not as a building block for complex applications. If it is good enough for simple web sites, then we should probably have a component set that supports it. Originally, I had put the current set under a “staticControls” folder thinking they wouldn’t support any customization of the sub-components, and called this “basic”, but slowly we added some customization. Then I moved them out of staticControls into just org/apache/flex/html Maybe it is time to start a different, richer component set under “skinnable” or in a different swc with different package names (org/apache/flex/skinnable) where the JS-side does not use the built-in elements and move some of the current components that don’t use the HTML elements into that set. Someday, I or someone will get around to breaking the Jquery components into their own SWC. Same for Cordova and CreateJS. So having more than one SWC of components needs to work. We want to offer choices since some folks are bound to certain UI libraries. The main benefit of FlexJS is using MXML and AS to glue the components together more quickly and reliably. And if folks can who aren’t bound to a particular toolkit can get better and faster visual customization via our toolchain and markup, even better. -Alex
