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