Whoah, Marc. Who put a burr under your saddle?? Did you read the documentation?? Are you using Eclipse and Spindle to ease the development process?? I will agree that there are things that could change, but then isn't that the nature of Open Source. Personally, I think JBoss leaves a LOT to be desired in the area of managability and usuability, but I don't go complaining about it (Doh! I think I just did....) If you don't like the way Tapestry is, contribute to help make it better. That is what a lot of us are trying to do. Open Source is about team work, making something better for the good of all users. Phrases like "drop the stupidity", "high on blah blah blah", and swearing don't help foster an attitude of team work and community.
----- Original Message ----- From: "marc fleury" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "'Tapestry Developer'" <[EMAIL PROTECTED]> Sent: Tuesday, October 08, 2002 8:41 PM Subject: [Tapestry-developer] RE: instances vs class/id vs type > 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 ------------------------------------------------------- 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
