IT Mill Toolkit Forum

As far as I understood, data model for UI controls is represented by Container interface, that is a datasource, so it can be implemented to provide controls with data from your own source. For instance, for table you can set it by table.setContainerDataSource(myDataSource)

JoaoGalli wrote:

what about TableModel?

Mmm, what about it? If I have understood correctly, the purpose of Swing TableModel is same as the Container in IT Mill Toolkit, although Container is a bit more generic and allows also for other data structures than tables. So, do you have some implementation of TableModel for some special data source that you want to use with IT Mill Toolkit? I guess you could write an adapter between TableModel and Container quite easily.

JoaoGalli wrote:

Here we go again,

what about TableModel?

Would this do the trick?

http://toolkit.itmill.com/demo/doc/api/com/itmill/toolkit/ui/Table.html#setContainerDataSource(com.itmill.toolkit.data.Container)

hmm, great implementation, I will try to adapt an HibernateContainer.

Is there a listener for when the scroll is rolled and the data must be retrieved from the server? I have made something like it in Swing, so the Hibernate adapter would search for more in the database. I know it's not a fast solution but in certain situations the list of items can be too big to put in the memory...

JoaoGalli - I suppose there is no such listener, however I may be mistaken. I think your implemented adapter must provide UI requested data and fetch them "on the fly" from the database instead from perfected array in memory.

Like in Swing's TableModel, here UI will call a Container's interface methods, requesting for data from particular rows, so you can do an actual database querying there.

For faster responses, you could pre-fetch data by 10... 100 items at once, for instance, when UI requests an item number 1, you can pre-fetch and cache items from 1 to 100.

Hope this helps,

Regards,
Dmitri

dll wrote:

JoaoGalli - I suppose there is no such listener, however I may be mistaken. I think your implemented adapter must provide UI requested data and fetch them "on the fly" from the database instead from perfected array in memory.

You are correct, see QueryContainer for an example.

JoaoGalli wrote:

hmm, great implementation, I will try to adapt an HibernateContainer.

If you could post even a prototype of your container implementation here - it would be great.

This is another suggestion I would like too give, not sure if it's possible or if it's already available, but it would be very good to be able to add other components to a panel header. Instead of just a String as title.

JoaoGalli wrote:

Another thing about the TabSheet in Echo2 is that we can put any Component in the Caption, in my case I've put a Close button component. You can put this as low priority.

Is there a case where it would be something else than close-button? Would it be sufficient to have "setTabClosingEnabled(Object tab)" feature?

JoaoGalli wrote:

This is another suggestion I would like too give, not sure if it's possible or if it's already available, but it would be very good to be able to add other components to a panel header. Instead of just a String as title.

What would be the use-cases? Close, collapse, ? IMO it might be better to support those directly than to allow any component to be put into header.

Joonas Lehtinen wrote:

What would be the use-cases? Close, collapse, ? IMO it might be better to support those directly than to allow any component to be put into header.

I think the main use-cases would be the ones you listed (close, collapse), but it would be more "widgetized", see this example:

http://gwt-ext.com/demo/#panels

I understand the meaning of restricting this access... and it's up to you.

JoaoGalli wrote:

Joonas Lehtinen wrote:

What would be the use-cases? Close, collapse, ? IMO it might be better to support those directly than to allow any component to be put into header.

I think the main use-cases would be the ones you listed (close, collapse), but it would be more "widgetized", see this example:

http://gwt-ext.com/demo/#panels

I understand the meaning of restricting this access... and it's up to you.

I can see how this would be useful; I'd probably subclass Panel, though - so that the basic panel is kept simple.

A alternative implementation that would be more restrictive, but potentially cause less problems (imagine adding a Table to the Panel header...), would be to make Panel (or a subclass) implement the Action.Container interface - adding an action to the panel would then add a button/icon to the header.

Just "thinking out loud" ;-)

//Marc

Marc Englund wrote:

A alternative implementation that would be more restrictive, but potentially cause less problems (imagine adding a Table to the Panel header...), would be to make Panel (or a subclass) implement the Action.Container interface - adding an action to the panel would then add a button/icon to the header.

Could we add the obvious minimize button directly to panel as a "first-class" feature? Something like setMinimizationAllowed() directly to the server-side component? This would be inherited to window, but it would added benefit.

IMO exact minimization behavior could be defined by the widgetset/theme. We might be able to implement this without any additional variables as height/width are already passed as vars... In fact this was one of the reasons to pass width/height as vars in year 2002. To be able to add minimize button in the "next" release

Joonas Lehtinen wrote:

Marc Englund wrote:

A alternative implementation that would be more restrictive, but potentially cause less problems (imagine adding a Table to the Panel header...), would be to make Panel (or a subclass) implement the Action.Container interface - adding an action to the panel would then add a button/icon to the header.

Could we add the obvious minimize button directly to panel as a "first-class" feature? Something like setMinimizationAllowed() directly to the server-side component? This would be inherited to window, but it would added benefit.

IMO exact minimization behavior could be defined by the widgetset/theme. We might be able to implement this without any additional variables as height/width are already passed as vars... In fact this was one of the reasons to pass width/height as vars in year 2002. To be able to add minimize button in the "next" release

Yeah, the minimize button is probably the most obvious feature, and could be added - but that would help if what you need is a 'configure' -button and a 'close' -button, so we might still want a more flexible API...

//Marc

Marc Englund wrote:

Yeah, the minimize button is probably the most obvious feature, and could be added - but that would help if what you need is a 'configure' -button and a 'close' -button, so we might still want a more flexible API...

That sounds like a toolbar api. That would also be quite natural for panels and windows alike. Or maybe even a "ToolbarLayout" that would contain one component in the "body" area and possibility to add any number of component to "toolbar" are with some grouping hints. Quite a bit larger project i think...