I definitely agree with Magic Hat and even more with Adam, especially about your "manners", marc. Maybe it's pathologic?
I believe, marc, that you missed the whole point of Tapestry. AG> Whoah, Marc. Who put a burr under your saddle?? Did you read the AG> documentation?? Are you using Eclipse and Spindle to ease the development AG> process?? I will agree that there are things that could change, but then AG> isn't that the nature of Open Source. Personally, I think JBoss leaves a AG> LOT to be desired in the area of managability and usuability, but I don't go AG> complaining about it (Doh! I think I just did....) If you don't like the AG> way Tapestry is, contribute to help make it better. That is what a lot of AG> us are trying to do. Open Source is about team work, making something AG> better for the good of all users. Phrases like "drop the stupidity", "high AG> on blah blah blah", and swearing don't help foster an attitude of team work AG> and community. AG> ----- Original Message ----- AG> From: "marc fleury" <[EMAIL PROTECTED]> AG> To: <[EMAIL PROTECTED]> AG> Cc: "'Tapestry Developer'" <[EMAIL PROTECTED]> AG> Sent: Tuesday, October 08, 2002 8:41 PM AG> 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 AG> ------------------------------------------------------- AG> This sf.net email is sponsored by:ThinkGeek AG> Welcome to geek heaven. AG> http://thinkgeek.com/sf AG> _______________________________________________ AG> Tapestry-developer mailing list AG> [EMAIL PROTECTED] AG> https://lists.sourceforge.net/lists/listinfo/tapestry-developer -- Saludos, Pablo mailto:[EMAIL PROTECTED] ------------------------------------------------------- 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
