ok, I have been here before we many kids and projects, so let's take it a step at a time and see if we can put your stuff on orbit. Drop the stupidity. Right now you are high in 'blah blah blah' land.
1- I don't want to declare the 200 pages that make up my "website" application. This is cute for 1/2/3 pages and really makes my nerves go "whoooom" when I think about the 200 pages I have 2- I don't want to write a .page for all my html and include my "template" component for every fucking page I have in my system. Dude, just these 2 points... just these 2 points, focus, focus, defense, defense, defaults, marc f > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 08, 2002 5:18 PM > To: marc fleury > Cc: Tapestry Developer > Subject: Re: instances vs class/id vs type > > > > 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
