> ok, > > <feedback on usability> > > I understand (after a couple of days) that your id and type are directly > linked to instances of a class. This is very confusing from a web > designer standpoint. I will share the blame, in that I am only now > really starting to crock what the web framework is about (mapping > getters in web-pages with state) but frankly there are a couple of > things that jump to mind in order to simplify. > > A lot of the configuration has to do with mapping the instance id to the > type of component (page and jwc). I may have missed by do you have a > concept where you can bypass the id and id->type mapping thereby > shortcutting a lot of the configuration that needs to go on. Frankly > only when I got the 'instance' view of the world did your configuration > start making sense and the 'defaults' become self evident. A lot of the > fields do not require mapping to do their work (most of the Border > example jumps to mind), yet only when I drew the (let me count them) 6 > files that are involved to display a simple Body did it start to click. > I believe we can remove 90% of the complexity for the simple > applications.
What I keep hearing from you (and you are in a class by yourself --- others either don't have your issues, or don't share them) is id vs. type. Obviously, some components you only use once within an entire page (i.e., Shell, Body) and others you use many times (Insert, TextField). I support we could change the Tapestry HTML template syntax to something like: <span jwcid="body:Body"> or <span jwcid="insertUserName:Insert"/> or <input type=text jwcid="inputName:TextField"/> That puts the id and the Type together, we then omit the type from the <component> element of the specification. Is that the kind of simplification you are looking for? We could scrap the whole idea of "required" parameters and make individual components produce a placeholder. So, an Insert component might insert its own id if its value parameter is not bound. You run the app, see the missing id, edit the spec to provide a real value. > > understand where I come from, it took me (marc fleury ;) 3 days to get > anything done, you badly need defaults. Also the Border example (I am > just trying to create my template for the JBoss website at this point) > shows clearly that you must include VERY REPETITIVE definitions in the > Home and Credo pages. This is useless and frankly I have little patience > for that kind of thing if I have to wait 3 days for it to make sense and > then realizing it is useless for the simple cases. > > Clearly having to define the component for every page is redundant and > cumbersome. I would like to just give the "type" of the component and be > done with it, the rest of the mappings don't give jack. I also hope we > agree on one thing: introduce the complexity as we go. One of the best > frameworks for that is WebObjects I am told, which you try to emulate. WebObjects is very very similar to Tapestry. Tapestry has a more useful HTML template format, and uses XML to describe embedded components rather than the home-brew format used by WOF. WOF does a somewhat better job managing server-side state (with a huge memory footprint). Tapestry is more flexible and adaptable than WOF. Specifically, WOF has the same id -> Type -> Java class mapping that Tapestry uses. HTML template has the id, .wod (equivalent of .page or .jwc) has the id->Type mapping which then yields the class to instantiate. > At this point you throw 100% of the complexity in the face of the user. > Adapt to the level with clever uses of defaults. This is the tricky > part, where your framework fails to be user-friendly. > And we are not agreeing here, and it doesn't match the two years of feedback I've gotten. I don't think we are throwing the complexity in user's faces. Tapestry boils down to this: if its dynamic, its a component. If its dynamic, you specify its parameters (almost no components are useful without parameters, Body being very much the exception to the rule). There is trickiness in Tapestry, related to properly managing server-side state, but that does come later. I just don't see where to simplify Tapestry without distorting it significantly. Should Tapestry "guess" the type of components from the id you assign? Should it "guess" the bindings for parameters? This feels just like the debates over typed vs. untyped variables, or checked vs. unchecked exceptions. I'm definately on the typed & checked camp, where you can do compile-time analysis to find errors. Does this mean a little extra discipline, to declare things before they are used? Yes. Ultimately, I feel you are looking for additional directives beyond the jwcid attribute. There's already one special directive, <span key=""/> that is used to access localized string properties. I have flirted with the idea of introducing more, to support some common cases (mostly involving Body, Insert and maybe Foreach), like: <body jwcid=":Body"> ... <span jwcid=":Insert" value="foo.bar.baz">Prototype text</span> <tr jwcid=":Foreach" source="foo" value="bar"> ... </tr> In this example, the leading colon would indicate, to Tapestry, that it should create an anonymous instance of the given type, and that it should apply the remaining attribute values as if they were <binding> elements. You'd lose some flexibility, you put more cruft in the HTML (but at least it still looks like HTML), but you do less in the specification. But this isn't Defaults! Defaults! Defaults! ... this is simply moving more of the specification into the HTML template. Managing the two files isn't an framework issue as much as it is a tool issue. Spindle (the Eclipse IDE plugin) does some of this for you, hiding the XML entirely and including Wizards and other Smart Stuff to streamline the process. About the .application file ... In theory, we could do a search through the classpath for pages (mandating, instead of suggesting, that page specification use the .page extension). We would assume that no two pages would have the same name, but be in different packages, and assume that the page name matches the name of the specification file. We could do something similar for .jwc files, with more caveats, such as excluding components located in the Tapestry JAR. However, once we add libraries to the mix, all bets are off. It is very likely that there will be conflicts in component names (for instance, everyone and his brother is working on some kind of "Tree" component right now). There might even be conflicts on page name with libraries. Perhaps there is a technical solution, but I don't see a foolproof, easy-to-explain option. In lieu of that, my comfort level is that the framework doesn't guess, it just knows what I've told it in the least ambiguous way possible. > marc f > > xxxxxxxxxxxxxxxxxx > Marc Fleury, Ph.D. > President, Founder > JBoss Group, LLC > xxxxxxxxxxxxxxxxxx > -- [EMAIL PROTECTED] http://tapestry.sf.net ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
