On Thu, Oct 16, 2014 at 12:03 PM, Alex Harui <aha...@adobe.com> wrote:
> Thanks for that info on Jquery and Dojo. Do they have skinning models? > How does it work? > > Styling is strictly through CSS. There are no other skinning model, per se. > 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. > Agreed, there does not have to be just one approach. Most common use of 9-slice skinning would be in buttons, scroll bars, title bars, icons, etc. It should be possible to add this support in a separate namespace. > > > > > > >> > >> 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. > Yes, 'skinnable' is the exact namespace I was thinking of too. I will work on the set up and share the progress soon. > > 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. > I think a very good looking default theme for FlexJS which can be customized easily (like Spark) is a good way to go. Thanks, Om > > -Alex > >
