RE: SwiXML for prototyping: table data

[email protected] Wed, 23 Feb 2005 10:38:20 -0600
Newsgroups gmane.comp.embedded.carlsbad-cubes
Message-ID <[email protected]>
"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