Re: SwiXML for prototyping: table data

There is some precedent for this. The JTree initializes with a default tree that 
is basically only good for seeing how the tree looks/behaves. This aids in the 
rapid prototyping phase. JTable does not have this behavior. For a prototype you 
should at least be able to specify the column names, in many cases these do not 
change. Actual data may be more trouble than its worth just for a prototype.

-- Gareth | mindshare.waves.ky

[email protected] wrote:
> "You are right there. Content in an MVC environment is usually specified in
> a model, so you may specify a model for your data."
> 
> I would usually agree.  The type of prototype I'm talking about is
> different, however.  When developing web-based applications in the past,
> I've used a methodology of paper prototype, followed by HTML prototype,
> followed by actual implementation.  The goal of the HTML prototype is to
> look a lot like the actual implementation and act like it just a little.
> 
> I would like to use SwiXML in an analogous role for Swing applications.  MVC
> can be a great thing, but it is an implementation issue.  Being forced to
> think in terms of models isn't convenient if you are just trying to
> determine if a user interface that seems good on paper is really reasonable
> on screen.  In the specific case of a JTable/TableModel, there is also the
> complication of table headers.  With default rendering, they are expressed
> via the model.  In most applications, however, they should be part of the
> view.
> 
> "You are talking about content but write UI elements, thus mixing data and
> its representation."
> 
> Good point.  That's because I'm only interested in how the UI looks and
> acts, yet it will look and act differently depending on what data is in it.
> I specified the data in terms of UI elements for just that reason.
> Specifying the data in terms of UI elements allows more freedom to specify
> exactly how the data will look.
> 
> Upon reflection, a more sensible course would be to write two new
> components, rather than trying to force this functionality onto table as I
> had suggested.  A "datatable" could provide a method of expressing tables
> in-line as succinctly as possible using default renderers.  A
> "componenttable" could provide a table of components.  Would it be possible
> to layer this on top of SwiXML?  Either way, I would appreciate any details
> you could provide. 
> 
> "An working idea might be a table model specifying the type of each cell or
> at least column. With more powerful converters there is a chance to convert
> the written XML in a working table model." 
> 
> Frank, could you sketch out some code examples of what you are suggesting?
> If there is a solution that meets my needs and keeps with the spirit of
> SwiXML, I would really like to find it.  Unfortunately, I can't really tell
> without more details.
> 
> Thanks,
> Curt
> 
> 
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>