Re: [PROPOSAL] Tapestry joins Jakarta
V. Cekvenich wrote: Struts 1.1 has something called tiles that are can be used for re-use, and at run time a tile can be bound to different beans, and more advanced capabilities. http://www.lifl.fr/~dumoulin/tiles/doc/tutorialBody.html and an advanced PDF (in doco of basicPortal which uses tiles and else where). I'm not sure that Tiles can be compared at all to what Tapestry is doing. Using JSP as a substrate for any kind of framework (and Tiles is based on JSP using a taglib) limits the things you can do to promote reuse: * Tapestry binds components together through the definitions (.jwc) file and allows a component to synchronize it's state with another component - allowing object values to be passed down and back up through the runtime component hierarchy. JSP allows only String communication between components via the jsp:include ... mechanism (by nesting jsp:parameter ... tags). Other communciation can be set up by setting attributes in the request, but this gets messy very quickly and is nearly unreadable for any reasonable size number of parameters. * JSP gets only one shot at producing a page - the rendering stage. Tapestry has a request cycle that sweeps through the component hiearchy with the request first (to allow components to extract request parameters and alter their internal state accordingly), then an action phase to take action (and get the resultant component, then a response (rendering) phase where output is written. This has many advantages, the least of which is that variable references on a page are consistent when read from top to bottom - a situation that is not true of JSP. This also allows the page to avoid having to manage the page buffer size, do forwarding, etc. and all that garbage. You have a return component that is rendered - no need to forward. * JSP is implictly tied to the filesystem by using paths to jsp files to denote a component name (all the jsp stuff calls it page - revealing it's nature). Other frameworks allow templates to be stored elsewhere (like a database). This JSP mechansim cripples any attempt at doing a runtime selection of template (for example choosing based on a user's chosen display language - not doing this forces you to rely on cumbersome resource bundles for all your i18n). * Tapestry components can have actions within them that can execute independently of your application - include the component and it will generate the links necessary to perform it's own actions. This is extremely different than the top-level controller approach of most other frameworks (Struts springs up foremost). A result of this is that almost all URL generation is done by the framework - you don't have to specify: %= request.getContextPath() %/myTemplate/whyMe/ohGodWhyMe.jsp to link to another page - you really shouldn't be concerned with URL generation, I think. * There are a lot more things that I'm leaving out. Bottom line: Tiles is a taglib for layout and Tapestry is a framework for building component-based applications. Two completely different beasts. Tapestry represents the leading edge of the new breed of web app frameworks - the component web app frameworks. WebObjects was the pioneer of this model and that framework is as old as the web (WO came out in 1995, I seem to recall). Tapestry is more component than thou, however :-) and solves some problems that WebObjects does not (like being free :-) - Drew -- +-+ Drew Davidson | OGNL Technology +-+ | Email: [EMAIL PROTECTED] / |Web: http://www.ognl.org / |Vox: (520) 531-1966 |Fax: (520) 531-1965\ | Mobile: (520) 405-2967 \ +-+ -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
Re: Naming issues
Henri Yandell wrote: On Mon, 21 Oct 2002, Nicola Ken Barozzi wrote: [EMAIL PROTECTED] wrote: Therefor I still think Jakarta Commons should fix their naming scheme. But that will have to be brought up there, not here. It's completely impractical, and will hurt Jakarta immensely. Oh, well, now that I think of it, this is only for projects that have already been released... Other opinions? Has everyone forgotten that it's not just commons that uses org.apache.projectName as their java package name within Jakarta. Ant is org.apache.tools.ant Turbine is org.apache.turbine Velocity is org.apache.velocity Struts is org.apache.struts etc. Sure, and Turbine will get a turbine.apache.org site, Ant an ant.apache.org site... but Commons? Bear in mind this is not just a website change. It breaks backwards compatibility of all jakarta projects [at least ones people code against] and will be confusing to users. Exactly what I said ;-) Citing myself: It's completely impractical, and will hurt Jakarta immensely. I wanted to highlight how following the other projects in the migration would effectively look like all code from Jakarta Commons should go into Apache Commons... hinting that instead of changing packagenames we could change project. A provocation, but still a possibility. Why not just decide to move the Jakarta Commons projects to Commons and the Sandbox ones to Incubator? Some of the Sandbox ones are blatant Commons projects which just aren't ready yet. I know that this is probably acceptable to the Incubator concept but wanted to make sure. Yes, in fact I'm ready to move to incubator the code of Morphos, which has some interested developers, two semi-active developers and no community yet. Equally, when does something go from Incubator to Commons? In Jakarta it seems to be on release of a 1.0. Do things have to stay in Incubator until they have a 1.0 release? When the community is deemed to be ready, that is when it works well following the Apache Project Guidelines, both in facts and spirit. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
Re: Newsletter
The consensus (mainly private mails) seems to be to stick to the monthly scheme and accept September as a blip. So business as usual - I'll call for contributions covering Sep + Oct sometime next week and post drafts from the 4th. Cheers, Rob - Original Message - From: Brian Ewins [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Thursday, October 17, 2002 5:33 PM Subject: Re: Newsletter As a reader, monthly is a good frequency. Maybe I'm expecting something different from the newsletter than you're looking to include? I look at the newsletter as being something like kernel traffic[1], the kernel cousins[2], or the 'eclectic' weblog[3]. It lets me keep up with the direction the community is heading in without reading all the lists. Announcements of new releases are actually the least interesting parts of the newsletter, since these get flagged up on the main news page anyway, and as you say arent all that frequent; feature-freezes and banches are more interesting. The most interesting things though are when something new appears on the horizon, a major new feature becomes usable (even if unstable), or there is a statement of the future direction of the project on the list. This kind of nugget is exactly what you need to keep abreast of the projects. Stuff like that did appear on struts dev in September - and it does every month! -, even though Sept was a light month for messages: http://nagoya.apache.org/eyebrowse/ReadMsg?listId=41msgNo=10612 - the Struts-EL package was checked in http://nagoya.apache.org/eyebrowse/ReadMsg?listName=struts-dev;jakarta.apache.orgmsgNo=10550 - which led to David Karr becoming a committer http://nagoya.apache.org/eyebrowse/ReadMsg?listName=struts-dev;jakarta.apache.orgmsgNo=10547 - Craig clarified whats going on with struts and JSF (you could make the whole months struts entry just by editing down this email!) If the editorial was going to the depth of kernel traffic, rather than the paragraph or two each list gets in the newsletter, I'd also have included some of the thread voting on validator behaviour, the responses to Craigs email about JSF, and possibly some of the discussion on browser caching[4]. eh, this isnt me volunteering as editor or anything ;) - I'm just giving my perspective on what I get out of reading the newsletter. Cheers, Baz [1] http://kt.zork.net/kernel-traffic/latest.html (summarizes the linux-kernel list) [2] http://kt.zork.net/wine/latest.html - for example, this is the wine kernel cousin [3] http://weblogs.userland.com/eclectic/ - eclectic covers the xml-dev list (by the former author of xml-deviant http://www.xml.com/pub/q/xmldeviant) [4] surprised noone mentioned that because ActionServlet doesn't override lastModified() conditional GETs on struts actions arent supported - but thats by the by. Joe Germuska wrote: As the volunteer editor for Struts for the first few newsletters, I'm wondering if monthly is the right frequency for these? Maybe it's because Struts is pretty focused on killing bugs for a 1.1 release, but that doesn't make for a lot of interesting news. Of course, the fact that various projects can participate or not according to their wishes may mean that circulating the newsletter every month is sensible, but that projects shouldn't feel obliged to conjure up news every month if there isn't much to say? We could probably survive with newsletters every 2 or 3 months instead of monthly. Joe Privacy and Confidentiality Notice The information contained in this E-Mail message is intended only for the person or persons to whom it is addressed. Such information is confidential and privileged and no mistake in transmission is intended to waive or compromise such privilege. If you have received it in error, please destroy it and notify us on the telephone number printed above. If you do not receive complete and legible copies, please telephone us immediately. Any opinions expressed herein including attachments are those of the author only. i-documentsystems Ltd. does not accept responsibility for the accuracy or completeness of the information provided or for any changes to this Email, however made, after it was sent. (Please note that it is your responsibility to scan this message for viruses). -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
Re: Naming issues
On Mon, 21 Oct 2002, Michael A. Smith wrote: On Mon, 21 Oct 2002, Nicola Ken Barozzi wrote: Why not just decide to move the Jakarta Commons projects to Commons and the Sandbox ones to Incubator? This is not a proposal for a diktat, but a *suggestion* for Jakarta Commons projects to take part of the Commons and Incubator Project creation. [EMAIL PROTECTED] As far as jakarta-commons goes (ignoring the sandbox/incubator), I sent a message to [EMAIL PROTECTED] asking whether this is something we, as committers on jakarta-commons, wanted to consider, and so far the only real reaction was major uncertainty due to the lack of defined structure/procedures in @commons.apache. hrrmmm... when'd this thread move from reorg@apache to general@jakarta? strange. Yeah, it tricked me too :) Moving Jakarta Commons stuff to Apache Commons stuff scares me if the people in charge of Apache Commons don't seem to 'get' Java. I suspect they're all reasonable people, but it's too easy to think of scary demands that might be made. Such as all Jakarta Commons must change dpackage names. This is gonna be a very bad experience for users. [Okay, I'm sounding like a scratch record. [What scares me is that I couldn't remember that phrase and was thinking 'for loop'] ]. Hen -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
OT: Presentation layer
One day W3.org will release xforms tag to replace the forms tag. Here me now, listen to me later. Here is a plug in for IE: http://www.FormsPlayer.com With great links. Exciting. Also http://jxforms.cybernd.at/ is also ok. .V -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
Re: Naming issues
[EMAIL PROTECTED] wrote: Therefor I still think Jakarta Commons should fix their naming scheme. But that will have to be brought up there, not here. It's completely impractical, and will hurt Jakarta immensely. Oh, well, now that I think of it, this is only for projects that have already been released... Other opinions? Has everyone forgotten that it's not just commons that uses org.apache.projectName as their java package name within Jakarta. Ant is org.apache.tools.ant Turbine is org.apache.turbine Velocity is org.apache.velocity Struts is org.apache.struts etc. Sure, and Turbine will get a turbine.apache.org site, Ant an ant.apache.org site... but Commons? Why not just decide to move the Jakarta Commons projects to Commons and the Sandbox ones to Incubator? This is not a proposal for a diktat, but a *suggestion* for Jakarta Commons projects to take part of the Commons and Incubator Project creation. [EMAIL PROTECTED] For the incubator the mailing list is not yet ready, will be soon. :-) I don't see a realistic proposal being made that renames all of the Jakarta Project source code. Why do you think I posted this message here? *gr* -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
Re: Naming issues
On Mon, 21 Oct 2002, Nicola Ken Barozzi wrote: [EMAIL PROTECTED] wrote: Therefor I still think Jakarta Commons should fix their naming scheme. But that will have to be brought up there, not here. It's completely impractical, and will hurt Jakarta immensely. Oh, well, now that I think of it, this is only for projects that have already been released... Other opinions? Has everyone forgotten that it's not just commons that uses org.apache.projectName as their java package name within Jakarta. Ant is org.apache.tools.ant Turbine is org.apache.turbine Velocity is org.apache.velocity Struts is org.apache.struts etc. Sure, and Turbine will get a turbine.apache.org site, Ant an ant.apache.org site... but Commons? Bear in mind this is not just a website change. It breaks backwards compatibility of all jakarta projects [at least ones people code against] and will be confusing to users. Why not just decide to move the Jakarta Commons projects to Commons and the Sandbox ones to Incubator? Some of the Sandbox ones are blatant Commons projects which just aren't ready yet. I know that this is probably acceptable to the Incubator concept but wanted to make sure. Equally, when does something go from Incubator to Commons? In Jakarta it seems to be on release of a 1.0. Do things have to stay in Incubator until they have a 1.0 release? Hen -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
Re: Naming issues
Sander Striker wrote: From: Nicola Ken Barozzi [mailto:nicolaken;apache.org] Sent: 21 October 2002 10:54 [...] I agree that what you say is the most sensible and correct way... The reality is that this *will* create tensions and flamewars. Like we're seeing on reorg@. Then you've seen nothing yet ;-) Defining a different namespace will just make things easier, by avoiding stupid discussions like the one that is happening now, because there *are* people that just want to break balls as we say. *nod* IMHO using org.apache.common.* is a possible solution. Also, when I say common_s_ I kept making errors in declarations because I expected common since it's a common namespace, not a commons namespace. Well, I find 'common' not too far off to object to it. We just have to make sure that it is well explained* what the Common PMC is about, since I can already see the confusion in such a name... ;-) It does feel like jumping through hoops though to fix earlier mistakes. Feels? ;-) It *is* hehehe Therefor I still think Jakarta Commons should fix their naming scheme. But that will have to be brought up there, not here. It's completely impractical, and will hurt Jakarta immensely. Oh, well, now that I think of it, this is only for projects that have already been released... Other opinions? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
Re: Naming issues
Therefor I still think Jakarta Commons should fix their naming scheme. But that will have to be brought up there, not here. It's completely impractical, and will hurt Jakarta immensely. Oh, well, now that I think of it, this is only for projects that have already been released... Other opinions? Has everyone forgotten that it's not just commons that uses org.apache.projectName as their java package name within Jakarta. Ant is org.apache.tools.ant Turbine is org.apache.turbine Velocity is org.apache.velocity Struts is org.apache.struts etc. I don't see a realistic proposal being made that renames all of the Jakarta Project source code. -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
Re: Naming issues
Michael A. Smith wrote: On Mon, 21 Oct 2002, Nicola Ken Barozzi wrote: Why not just decide to move the Jakarta Commons projects to Commons and the Sandbox ones to Incubator? This is not a proposal for a diktat, but a *suggestion* for Jakarta Commons projects to take part of the Commons and Incubator Project creation. [EMAIL PROTECTED] As far as jakarta-commons goes (ignoring the sandbox/incubator), I sent a message to [EMAIL PROTECTED] asking whether this is something we, as committers on jakarta-commons, wanted to consider, and so far the only real reaction was major uncertainty due to the lack of defined structure/procedures in @commons.apache. Yeah, that's why I posted it here! Come on guys, come over to [EMAIL PROTECTED], let's make ourselves heard, help create the rules there, so finally Commons can have it's top-level project! It's not something that has to be imposed, we can help over there! [EMAIL PROTECTED] hrrmmm... when'd this thread move from reorg@apache to general@jakarta? strange. hehehe, when I cross-posted ;-) Oh, and now I'm at it, here it goes, welcome to the discussion commons-dev! :-D -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org
