2.0 Core Components

[darkfrog]

One of the main changes being made in jSeamless 2.0 is that the "core" is going to be absolutely tiny in comparison to 1.0.  To that end I'm trying to define a list of the "core" components that are necessary in order to build more complex UIs.  For example, a ComboBox will not end up on the this list since it is a combination of several Components.

Please feel free to comment on anything that should be added or a more complex scenario that won't be accounted for with this set of components:

• Button
• CheckBox
• TextInput
• Label
• FileInput
• RadioButton
• Image
• WebBrowser
• CustomComponent
• Container

Now, it is relevant to point out that another big change in 2.0 will be a single "Container" that uses LayoutManagers instead of having separate Container classes.  Also, Label will not be limited to a single-line text component but will also support multi-line.

[syam]

Scrollbar - Not part of the basic? May be part of the Layout spec.
Table - Complex component.

I think, we can just have Container as the base ?? !!
Most properties of Container can be just attributes of Compoent itself.
For example: Label extends Container, can add images/icons, texts etc. to it. Layout of this container determines how the icon, text etc. get aligned and painted. "add" method is very generic - add(Object object) to the Container!!

Just wild ideas...

[darkfrog]

ScrollBar is a good think to mention.  I've had a few different ideas about how to handle that, but haven't really come to an ultimate conclusion yet of how best to support scrollbars in 2.0.

Container as a base is actually the way Swing was written, and I actually hate it.   Core Components are exactly that, core. They really have no business being containers to themselves.  It would also be problematic if we attempted to do such a thing since when possible the implementations want to take advantage of the built-in pre-existing components and most will not work with this mentality and would have to be wrapped in another container.  For example, consider a Label in HTML.  It would end up having to be wrapped in a div for every label in case someone decided to add children to it.  This makes each component much heavier than need-be.

Really what I'm trying to focus towards here is the absolute core for performance above all else and then standardization so every implementation can look nearly identical in their respective UIs.

[syam]

OK, I do agree with that. Container should not be the base.

Can we have a ContainerInterface? Some of the base components can implement this.
For example: setLayout(...) can be defined in ContainerInterface and may be, Label can implement that to define its layout.

In 1.x, CustomerComponent does not have "Container" behavior and because Java is not very aspect oriented, we can not create that behavior on the fly. If CustomerComponent implements ContainerInterface, that can be resolved to some extend.

Practically, getComponent() method of CustomComponent always returns a Container. (I can't think of just a Component because in that case, one would have extended the Component itself).
So, it must be getContainer()  and should return a ContainerInterface ?
getLabel() should be a defined in ContainerInterface.

Should we think of a ComponentInerface too? This may allow us to add other stuff to the UI in a generic way.

[darkfrog]

Can we have a ContainerInterface? Some of the base components can implement this.
For example: setLayout(...) can be defined in ContainerInterface and may be, Label can implement that to define its layout.

One of the limitations of jSeamless is that for these core items I have to provide for the lowest common denominator. For example, in most implementations Label would not have layout options really at all. However, I realize that these core components will be severely limiting in and of themselves, so I'm intending to create wrappers for most components in something similar to what the "extensions" project is now. It would contain niceties like AutoCompleteTextInput, ComboBox, etc. all the stuff that a standard UI should have. The core is not meant to be a complete UI in and of itself, but the core building blocks to get there.

In 1.x, CustomerComponent does not have "Container" behavior and because Java is not very aspect oriented, we can not create that behavior on the fly. If CustomerComponent implements ContainerInterface, that can be resolved to some extend.

What I currently have in 2.0 is an interface WrapperComponent that has "hasChildren" and "getChildren" methods.  CustomComponent, View, and Container will all implement this interface.

Practically, getComponent() method of CustomComponent always returns a Container. (I can't think of just a Component because in that case, one would have extended the Component itself).
So, it must be getContainer()  and should return a ContainerInterface ?
getLabel() should be a defined in ContainerInterface.

Not really, there may be many cases where you want to extend something like TextInput, but you don't want to give just anyone the ability to call setText for example. Using CustomComponent gives you the ability to only expose what you want so as not to confuse people.

Should we think of a ComponentInerface too? This may allow us to add other stuff to the UI in a generic way.

I came up with an ExtensionComponent idea yesterday that would be implemented by Components that are outside of the core so either implementations can add their own specialized components, or we could have a higher level set of components for implementations that wish to support them.  Also, this could be used by implementations that want to add functionalilty beyond the standard components, say for a Button they have a "direction" property that defines the direction the text displays. This wouldn't be visible by default to the normal jSeamless Button, but they could extend Button and implement ExtensionComponent to have BetterButton that has additional properties on it.

Using the extensions ideology should help to close the gap with one of the biggest limitations 1.0 faced: lacking specialized support for specific implementations.

[darkfrog]

After further thought I believe I will stick with the same concept I have today in jSeamless 1.0 for scrollbars. Container would simply define horizontal and vertical ScrollPolicy to determine whether they should be set and they would always default to OFF for performance.

I haven't decided if something like Label (that supports single and multi-line) would have inherent scrolling support or whether they should always be wrapped in a Container that would manage their scrolling for them.

[syam]

I like the idea of the ComponentWrapper. It will be solution to some of my arguments.

Also, the ExtensionComponent idea is good.

[syam]

After further thought I believe I will stick with the same concept I have today in jSeamless 1.0 for scrollbars. Container would simply define horizontal and vertical ScrollPolicy to determine whether they should be set and they would always default to OFF for performance.

I haven't decided if something like Label (that supports single and multi-line) would have inherent scrolling support or whether they should always be wrapped in a Container that would manage their scrolling for them.

Can all components negotiate with their parent (container) to get the appropriate size. Then, the component can decide to "crop themselves off" or to "scroll within the permitted size" depending up on their settings?

Also, I like quite a few of the concepts in Android (Google's mobile OS). May be we can learn stuff from there too.

[darkfrog]

I like the idea of the ComponentWrapper. It will be solution to some of my arguments.

ComponentWrapper already exists in 1.0 and has for a while.

Can all components negotiate with their parent (container) to get the appropriate size. Then, the component can decide to "crop themselves off" or to "scroll within the permitted size" depending up on their settings?

That is typically the responsibility of the Container or LayoutManager to handle that sort of thing because otherwise every component would have to support every layout manager and there would be no possibility to create custom layout managers.

Also, I like quite a few of the concepts in Android (Google's mobile OS). May be we can learn stuff from there too.

I haven't done much with it, so please pass along any ideas you've gleaned from it.