Re: An Eclipse Like WebApp Framework? -- a proposal
On Wed, 06 Oct 2004 08:26:20 -0700, Michael McGrady wrote: PROPOSAL/SUGGESTION If you were interested, we might try doing this as a Struts Branch, maybe calling it Branch or Struts Branch, with a really up-to- date modular structure along the lines indicated in Stuart Dabbs Halloway's Component Development for the Java Program, keeping only a real kernel as the base. We could pop it up on SourceForge. I bet we could even recruit The Halloway Himself, even though he has gone elsewhere for the majority of his time right now. I don't think this presently exists. I do think that it would sell like wildfire to users. This would allow the user, in effect, to become automatic developers through their plugins and extensions. This would build a framework without ego in the core. If you come up with some actual code to commit, consisder setting up shop at Struts SourceForge. We'll be bringing Struts Control Flow and Struts Scripting over soon, so they will some vacancies :) Incidentally, the Chain of Responsibility, which is the core of the upcoming Struts 1.3 request processor, does support drag-and-drop components. You can build a JAR so that Chain will automatically plug it into the catalog. One reason Struts Committers aren't chaffing at the bit to explore other proposals is that many of the things people mention would already be supported by Struts chain. We think Chain is going to scratch most of our itches, and so we don't feel the need to shop. Getting a 1.2.x stable release was a long time coming, but now we can finally get back to business. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Eclipse Like WebApp Framework? -- a proposal
Looks like looking at what is being done with chain would be the first thing. I have a question and a comment. If you don't have time for the qeustion, I certainly will understand. QUESTION: Component drag and drop? Is the drag and drop for apps using the chaing of responsibility framework or for alternative coding of the framework parts themselves? I.e. is this like dropping a war into Tomcat or like dynamically updating a class without restarting the client of the class? COMMENT I understand entirely on the committers already being on their own path at this point in time. I am sure the product will be cool. I have always believed criticism is more useful and usually more honest than praise, but I am well aware of the considerable accomplishments of this and other Apache teams. Apache is somewhat of a minor miracle. Michael McGrady On Wed, 06 Oct 2004 08:26:20 -0700, Michael McGrady wrote: PROPOSAL/SUGGESTION If you were interested, we might try doing this as a Struts Branch, maybe calling it Branch or Struts Branch, with a really up-to- date modular structure along the lines indicated in Stuart Dabbs Halloway's Component Development for the Java Program, keeping only a real kernel as the base. We could pop it up on SourceForge. I bet we could even recruit The Halloway Himself, even though he has gone elsewhere for the majority of his time right now. I don't think this presently exists. I do think that it would sell like wildfire to users. This would allow the user, in effect, to become automatic developers through their plugins and extensions. This would build a framework without ego in the core. If you come up with some actual code to commit, consisder setting up shop at Struts SourceForge. We'll be bringing Struts Control Flow and Struts Scripting over soon, so they will some vacancies :) Incidentally, the Chain of Responsibility, which is the core of the upcoming Struts 1.3 request processor, does support drag-and-drop components. You can build a JAR so that Chain will automatically plug it into the catalog. One reason Struts Committers aren't chaffing at the bit to explore other proposals is that many of the things people mention would already be supported by Struts chain. We think Chain is going to scratch most of our itches, and so we don't feel the need to shop. Getting a 1.2.x stable release was a long time coming, but now we can finally get back to business. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Eclipse Like WebApp Framework? -- a proposal
I have a proposal at the bottom of this email. I know exactly what you want. Struts is a wonderful potential base for this. I have been crying for this in Struts, but have only gotten resistence from the more vocal committers and, I think, a failure to see what the problem is. Right now Struts includes way too much application specific coding in the core. With a pretty concerted team effort it could be cleaned up, but with 1.3 on the way, that does not seem to be wise at the moment. With Struts 1.2 the problem seems to be increasing rather than decreasing. I really think there is a failure to understand the problem. I am not too effective at advocating this, because I don't have the time to assuage feelings around these issues. With Struts 1.3 coming along, I have just bided my time and kept a copy of Struts to consider starting an offshoot that makes the core the core and the rest modular with plugins and extensibility. This might not be too hard, because the main thing is removing dependencies. PROPOSAL/SUGGESTION If you were interested, we might try doing this as a Struts Branch, maybe calling it Branch or Struts Branch, with a really up-to-date modular structure along the lines indicated in Stuart Dabbs Halloway's Component Development for the Java Program, keeping only a real kernel as the base. We could pop it up on SourceForge. I bet we could even recruit The Halloway Himself, even though he has gone elsewhere for the majority of his time right now. I don't think this presently exists. I do think that it would sell like wildfire to users. This would allow the user, in effect, to become automatic developers through their plugins and extensions. This would build a framework without ego in the core. Michael McGrady James Mitchell wrote: Apache Struts provides just what you want ;) That's about as generic as you can get. - Original Message - From: Rob Evans [EMAIL PROTECTED] Folks, I'm wondering if anyone has thought about developing an Eclipse like WebApp framework. The idea is to provide an application shell and a contribution (think plugin) mechanism. Contributions could include, tabs, navigation, help, etc.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Eclipse Like WebApp Framework? -- a proposal
Are either Tapestry or Zope the kind of things you're talking about here? They are both component based web app frameworks. If those are not what you're talking about, whats the difference? dave On Wed, 2004-10-06 at 11:26, Michael McGrady wrote: I have a proposal at the bottom of this email. I know exactly what you want. Struts is a wonderful potential base for this. I have been crying for this in Struts, but have only gotten resistence from the more vocal committers and, I think, a failure to see what the problem is. Right now Struts includes way too much application specific coding in the core. With a pretty concerted team effort it could be cleaned up, but with 1.3 on the way, that does not seem to be wise at the moment. With Struts 1.2 the problem seems to be increasing rather than decreasing. I really think there is a failure to understand the problem. I am not too effective at advocating this, because I don't have the time to assuage feelings around these issues. With Struts 1.3 coming along, I have just bided my time and kept a copy of Struts to consider starting an offshoot that makes the core the core and the rest modular with plugins and extensibility. This might not be too hard, because the main thing is removing dependencies. PROPOSAL/SUGGESTION If you were interested, we might try doing this as a Struts Branch, maybe calling it Branch or Struts Branch, with a really up-to-date modular structure along the lines indicated in Stuart Dabbs Halloway's Component Development for the Java Program, keeping only a real kernel as the base. We could pop it up on SourceForge. I bet we could even recruit The Halloway Himself, even though he has gone elsewhere for the majority of his time right now. I don't think this presently exists. I do think that it would sell like wildfire to users. This would allow the user, in effect, to become automatic developers through their plugins and extensions. This would build a framework without ego in the core. Michael McGrady James Mitchell wrote: Apache Struts provides just what you want ;) That's about as generic as you can get. - Original Message - From: Rob Evans [EMAIL PROTECTED] Folks, I'm wondering if anyone has thought about developing an Eclipse like WebApp framework. The idea is to provide an application shell and a contribution (think plugin) mechanism. Contributions could include, tabs, navigation, help, etc.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Eclipse Like WebApp Framework? -- a proposal
Comments inline On Wed, 06 Oct 2004 08:26:20 -0700, Michael McGrady [EMAIL PROTECTED] wrote: I have a proposal at the bottom of this email. I know exactly what you want. Struts is a wonderful potential base for this. I have been crying for this in Struts, but have only gotten resistence from the more vocal committers and, I think, a failure to see what the problem is. Right now Struts includes way too much application specific coding in the core. With a pretty concerted team effort it could be cleaned up, but with 1.3 on the way, that does not seem to be wise at the moment. With Struts 1.2 the problem seems to be increasing rather than decreasing. I really think there is a failure to understand the problem. Could be. I for one am still trying to nail down the issues. Why is having a single WebApp that utilizes Inversion of Control and plugins better than just having several webapps that use the same UI libraries and abide by the same standards? From experience, I know that this has not worked well for large teams, but I'm not I can clearly articulate why, yet. I am not too effective at advocating this, because I don't have the time to assuage feelings around these issues. When it comes to architecture and design, feelings suck. ;-) With Struts 1.3 coming along, I have just bided my time and kept a copy of Struts to consider starting an offshoot that makes the core the core and the rest modular with plugins and extensibility. This might not be too hard, because the main thing is removing dependencies. PROPOSAL/SUGGESTION If you were interested, we might try doing this as a Struts Branch, maybe calling it Branch or Struts Branch, with a really up-to-date modular structure along the lines indicated in Stuart Dabbs Halloway's Component Development for the Java Program, keeping only a real kernel as the base. We could pop it up on SourceForge. I bet we could even recruit The Halloway Himself, even though he has gone elsewhere for the majority of his time right now. I don't think this presently exists. I do think that it would sell like wildfire to users. This would allow the user, in effect, to become automatic developers through their plugins and extensions. This would build a framework without ego in the core. I appreciate your interest and I'm flattered that you think this is a good idea. Before we get to far down the road I'd like to surface more of the problems and understand what it is we're talking about a little more. Michael McGrady James Mitchell wrote: Apache Struts provides just what you want ;) That's about as generic as you can get. - Original Message - From: Rob Evans [EMAIL PROTECTED] Folks, I'm wondering if anyone has thought about developing an Eclipse like WebApp framework. The idea is to provide an application shell and a contribution (think plugin) mechanism. Contributions could include, tabs, navigation, help, etc.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: An Eclipse Like WebApp Framework? -- a proposal
-Original Message- From: Rob Evans [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 10:45 AM To: Struts Users Mailing List Subject: Re: An Eclipse Like WebApp Framework? -- a proposal snip When it comes to architecture and design, feelings suck. ;-) You wouldn't know that by the fervour that some people have when they advocate one over another! Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 Some problems are so complex that you have to be highly intelligent and well-informed just to be undecided about them. - Laurence J. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Eclipse Like WebApp Framework? -- a proposal
This would build a framework without ego in the core. Michael, What does this mean? David Michael McGrady [EMAIL PROTECTED]To: Struts Users Mailing List [EMAIL PROTECTED] ady.com cc: Subject: Re: An Eclipse Like WebApp Framework? -- a proposal 10/06/2004 11:26 AM Please respond to Struts Users Mailing List I have a proposal at the bottom of this email. I know exactly what you want. Struts is a wonderful potential base for this. I have been crying for this in Struts, but have only gotten resistence from the more vocal committers and, I think, a failure to see what the problem is. Right now Struts includes way too much application specific coding in the core. With a pretty concerted team effort it could be cleaned up, but with 1.3 on the way, that does not seem to be wise at the moment. With Struts 1.2 the problem seems to be increasing rather than decreasing. I really think there is a failure to understand the problem. I am not too effective at advocating this, because I don't have the time to assuage feelings around these issues. With Struts 1.3 coming along, I have just bided my time and kept a copy of Struts to consider starting an offshoot that makes the core the core and the rest modular with plugins and extensibility. This might not be too hard, because the main thing is removing dependencies. PROPOSAL/SUGGESTION If you were interested, we might try doing this as a Struts Branch, maybe calling it Branch or Struts Branch, with a really up-to-date modular structure along the lines indicated in Stuart Dabbs Halloway's Component Development for the Java Program, keeping only a real kernel as the base. We could pop it up on SourceForge. I bet we could even recruit The Halloway Himself, even though he has gone elsewhere for the majority of his time right now. I don't think this presently exists. I do think that it would sell like wildfire to users. This would allow the user, in effect, to become automatic developers through their plugins and extensions. This would build a framework without ego in the core. Michael McGrady James Mitchell wrote: Apache Struts provides just what you want ;) That's about as generic as you can get. - Original Message - From: Rob Evans [EMAIL PROTECTED] Folks, I'm wondering if anyone has thought about developing an Eclipse like WebApp framework. The idea is to provide an application shell and a contribution (think plugin) mechanism. Contributions could include, tabs, navigation, help, etc.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Eclipse Like WebApp Framework? -- a proposal
Rob Evans wrote: Could be. I for one am still trying to nail down the issues. Why is having a single WebApp that utilizes Inversion of Control and plugins better than just having several webapps that use the same UI libraries and abide by the same standards? From experience, I know that this has not worked well for large teams, but I'm not I can clearly articulate why, yet. I agree totally. Measure twice, cut once. This may take ten measures. I appreciate your interest and I'm flattered that you think this is a good idea. Before we get to far down the road I'd like to surface more of the problems and understand what it is we're talking about a little more. I could not agree, again, more. In the larger picture, you have to make sure your plans include eventual integration with IDEs. However, the biggest thing with component programming, I think, is to promote reuse by promoting the survival of the fittest plugin, which means creating a structure where anyone can plug in as deeply as can possibly be built into the struture. I do think that Struts' basic, core, architecture is a good, excellent, idea for a kernel. I am sure that Craig would have some thoughts about how he might do something different, if anything, at the core. If some direction from people with a larger perspective (like Craig and the other brigher lights in this area) were to be applied to a sort of online discussion of a wish list for a component framework core, that would be great. I would especially be interested myself in what Halloway would have to say. I think I am going to try and tweak his interest enough to get his thoughts on your notion. Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Eclipse Like WebApp Framework? -- a proposal
Just to make sure the bases are covered, have you investigated JSF and found it lacking? Quoting Rob Evans [EMAIL PROTECTED]: Comments inline On Wed, 06 Oct 2004 08:26:20 -0700, Michael McGrady [EMAIL PROTECTED] wrote: I have a proposal at the bottom of this email. I know exactly what you want. Struts is a wonderful potential base for this. I have been crying for this in Struts, but have only gotten resistence from the more vocal committers and, I think, a failure to see what the problem is. Right now Struts includes way too much application specific coding in the core. With a pretty concerted team effort it could be cleaned up, but with 1.3 on the way, that does not seem to be wise at the moment. With Struts 1.2 the problem seems to be increasing rather than decreasing. I really think there is a failure to understand the problem. Could be. I for one am still trying to nail down the issues. Why is having a single WebApp that utilizes Inversion of Control and plugins better than just having several webapps that use the same UI libraries and abide by the same standards? From experience, I know that this has not worked well for large teams, but I'm not I can clearly articulate why, yet. I am not too effective at advocating this, because I don't have the time to assuage feelings around these issues. When it comes to architecture and design, feelings suck. ;-) With Struts 1.3 coming along, I have just bided my time and kept a copy of Struts to consider starting an offshoot that makes the core the core and the rest modular with plugins and extensibility. This might not be too hard, because the main thing is removing dependencies. PROPOSAL/SUGGESTION If you were interested, we might try doing this as a Struts Branch, maybe calling it Branch or Struts Branch, with a really up-to-date modular structure along the lines indicated in Stuart Dabbs Halloway's Component Development for the Java Program, keeping only a real kernel as the base. We could pop it up on SourceForge. I bet we could even recruit The Halloway Himself, even though he has gone elsewhere for the majority of his time right now. I don't think this presently exists. I do think that it would sell like wildfire to users. This would allow the user, in effect, to become automatic developers through their plugins and extensions. This would build a framework without ego in the core. I appreciate your interest and I'm flattered that you think this is a good idea. Before we get to far down the road I'd like to surface more of the problems and understand what it is we're talking about a little more. Michael McGrady James Mitchell wrote: Apache Struts provides just what you want ;) That's about as generic as you can get. - Original Message - From: Rob Evans [EMAIL PROTECTED] Folks, I'm wondering if anyone has thought about developing an Eclipse like WebApp framework. The idea is to provide an application shell and a contribution (think plugin) mechanism. Contributions could include, tabs, navigation, help, etc.. -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Eclipse Like WebApp Framework? -- a proposal
[EMAIL PROTECTED] wrote: This would build a framework without ego in the core. Michael, What does this mean? David Great implementations are eclipsed. Not only being open to or allowing for this but specifically creating an environment in which it is easy to do is the idea. Without specific implementations in the core so that competing ideas could be plugged in and could stand on their merits rather than on some sort of Lord of the Flies advocacy. Essentially, it means protecting us from ourselves and not allowing us to code ourselves into corners like painters paint themselves into corners. No matter how good the idea, in the long run it probably will be eclipsed. Newton was a great, unimaginably great, thinker, and pretty much everything, if not everything, he said was false. Blah, blah. Kernel architecture with component development is the way to go, in my opinion. The idea is to make the kernel as small as possible. You can even have sample build-outs from the kernel as a starter idea. The smaller the kernel, the better. Michael McGrady
Re: An Eclipse Like WebApp Framework? -- a proposal
On Wed, 06 Oct 2004 08:59:26 -0700, Michael McGrady [EMAIL PROTECTED] wrote: Rob Evans wrote: Could be. I for one am still trying to nail down the issues. Why is having a single WebApp that utilizes Inversion of Control and plugins better than just having several webapps that use the same UI libraries and abide by the same standards? From experience, I know that this has not worked well for large teams, but I'm not I can clearly articulate why, yet. I agree totally. Measure twice, cut once. This may take ten measures. I appreciate your interest and I'm flattered that you think this is a good idea. Before we get to far down the road I'd like to surface more of the problems and understand what it is we're talking about a little more. I could not agree, again, more. In the larger picture, you have to make sure your plans include eventual integration with IDEs. However, the biggest thing with component programming, I think, is to promote reuse by promoting the survival of the fittest plugin, which means creating a structure where anyone can plug in as deeply as can possibly be built into the struture. I do think that Struts' basic, core, architecture is a good, excellent, idea for a kernel. I am sure that Craig would have some thoughts about how he might do something different, if anything, at the core. If some direction from people with a larger perspective (like Craig and the other brigher lights in this area) were to be applied to a sort of online discussion of a wish list for a component framework core, that would be great. I would especially be interested myself in what Halloway would have to say. I think I am going to try and tweak his interest enough to get his thoughts on your notion. It sounds like we are on the same page regarding the nature of the solution i.e. we're after something that looks like components. I'm sure Craig and Halloway will have something to say about this if you can get their attention. I'm not sure that in the end a full blown component model for webapp is necessary. Do we really need to start/stop/reload webapp contributions? Is it even possible to reload a contribution without bouncing the webapp. Maybe, I don't know. Most of the light weight containers don't bother with hotdeployment and instead focus on the IOC/Dependancy Injection. Perhaps, this would be a good place to start? I'm tempted to send an email to one of the eclipse lists and see what they think. Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Eclipse Like WebApp Framework? -- a proposal
On Wed, 6 Oct 2004 12:01:15 -0400, Kris Schneider [EMAIL PROTECTED] wrote: Just to make sure the bases are covered, have you investigated JSF and found it lacking? I've not. Do you know much about it? I was under the impression that its purpose in life was to provided support for UI widget development. [snip] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: An Eclipse Like WebApp Framework? -- a proposal
Michael - I would have to say...get working. It is pretty obvious from this and the dev list that you are very unhappy with struts and its developers. While struts does some of what you want, it is very lacking for you. I think it is also obvious that your view of what struts should be does not coincide with most of the struts developers or users, and would most likely not become Struts v3.0. Just submitting a proposal of this nature will go nowhere, (If my knowledge of open source history is any good...) so don't just submit a proposal. Sit down and work on an implementation of what you propose. Put it up on sourceforge. Advertise it here (with an appropriate OT label of course). If it is any good people WILL start using it, and WILL start helping out with it. If it is good enough, it could make struts obsolete as people start using your framework instead, which nobody (including the struts committers...) would have a problem with. If it is not any good they won't, but you will have a start on what you are looking for at least. Your initial crack at the project may not even have to be any good, look at Linux 0.1. Without some sort of code to go on though, nobody will probably ever take this up...this is a proposal that scratches YOUR specific itch, so you have to be the impetus behind it. If you just submit the proposal, or if you try to build a team or get a committee together to discuss it or whatever this will go nowhere. Open source projects that do these administrative type things before they have any code are doomed to failure in my opinion, unless they have some big blue backing ;) The ultimate example of this in my opinion is the Freedows project of a few years back...but that is getting off track. Anyways, this is the way I see it: You can talk all you want, and malign struts and its developers all you want, but until you start implementing what you want, nothing will happen. Matt p.s. I kind of hinted at this above, but I am kind of offended by the build a framework without ego in the core comment in your proposal. It seems to me that it was a personal attack on the struts committers and how they drive the development. Just because the Struts developers do not agree with your views sometimes, it does not mean the project is ego driven. I have found the committers and the user/dev lists to be some of the best, most helpful, least ego driven people in the open source community. I can honestly say that I have never seen the power of being a committer go to anybody's head. Michael McGrady wrote: I have a proposal at the bottom of this email. I know exactly what you want. Struts is a wonderful potential base for this. I have been crying for this in Struts, but have only gotten resistence from the more vocal committers and, I think, a failure to see what the problem is. Right now Struts includes way too much application specific coding in the core. With a pretty concerted team effort it could be cleaned up, but with 1.3 on the way, that does not seem to be wise at the moment. With Struts 1.2 the problem seems to be increasing rather than decreasing. I really think there is a failure to understand the problem. I am not too effective at advocating this, because I don't have the time to assuage feelings around these issues. With Struts 1.3 coming along, I have just bided my time and kept a copy of Struts to consider starting an offshoot that makes the core the core and the rest modular with plugins and extensibility. This might not be too hard, because the main thing is removing dependencies. PROPOSAL/SUGGESTION If you were interested, we might try doing this as a Struts Branch, maybe calling it Branch or Struts Branch, with a really up-to-date modular structure along the lines indicated in Stuart Dabbs Halloway's Component Development for the Java Program, keeping only a real kernel as the base. We could pop it up on SourceForge. I bet we could even recruit The Halloway Himself, even though he has gone elsewhere for the majority of his time right now. I don't think this presently exists. I do think that it would sell like wildfire to users. This would allow the user, in effect, to become automatic developers through their plugins and extensions. This would build a framework without ego in the core. Michael McGrady James Mitchell wrote: Apache Struts provides just what you want ;) That's about as generic as you can get. - Original Message - From: Rob Evans [EMAIL PROTECTED] Folks, I'm wondering if anyone has thought about developing an Eclipse like WebApp framework. The idea is to provide an application shell and a contribution (think plugin) mechanism. Contributions could include, tabs, navigation, help, etc.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Eclipse Like WebApp Framework? -- a proposal
I certainly don't know enough about it to point you at its various pieces and say, here's just what you need (partly because I'm not crystal clear on what your requirements are). It was mainly just a Pavlovian reaction to discussions about web component frameworks and designing with IDEs in mind, etc. http://java.sun.com/j2ee/javaserverfaces/ Based on what it sounds like you're asking for, I'd say it's worth your time to investigate the space of Java standards to make sure something useful doesn't already exist. Quoting Rob Evans [EMAIL PROTECTED]: On Wed, 6 Oct 2004 12:01:15 -0400, Kris Schneider [EMAIL PROTECTED] wrote: Just to make sure the bases are covered, have you investigated JSF and found it lacking? I've not. Do you know much about it? I was under the impression that its purpose in life was to provided support for UI widget development. [snip] -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Eclipse Like WebApp Framework? -- a proposal
PROPOSAL/SUGGESTION I was a big fan of the component software model advocated by a technology called OpenDoc developed by Apple, IBM, and Novell back in the mid 90's... http://en.wikipedia.org/wiki/OpenDoc Ironically, Steve Jobs killed off this technology because the thought was that Java Beans would be a better solution. This has not happened...yet. This is probably because Sun did a lousy job of evangelizing the potential of technologies like the bean box and others in the Glasgow suite of Java Bean technologies. When I started doing web development I naturally started looking for a similar software model and framework that I could apply to this space. I believe my wait is finally over and the answer is portlets... http://portals.apache.org/ Think of a portal as simply a collection of compound documents made up of portlets and I think you will see how I got here from there. Even though this technology is in its infancy, I believe that there has already been some movement in the Struts community to provide support for JSR-168 in an upcoming release. I will be doing all that I can to ensure that this effort is successful. Before anyone starts a new Struts branch, before fo so I urge them to evaluate supporting the development of standardized Struts portlets. In regards to establishing an IDE for this technology I would think that a portal for developing, or simply assembing, portlets would be a natural solution. Scott __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Eclipse Like WebApp Framework? -- a proposal
Rob Evans wrote: On Wed, 06 Oct 2004 08:59:26 -0700, Michael McGrady [EMAIL PROTECTED] wrote: Rob Evans wrote: Could be. I for o It sounds like we are on the same page regarding the nature of the solution i.e. we're after something that looks like components. I'm sure Craig and Halloway will have something to say about this if you can get their attention. I hope so. I have to admit that I cannot approach the horsepower they would bring to a discussion like this. I am convinced, however, that the smaller the core and the more extensible the whole design, the better things are. Getting the kernel right, however, and getting a design for growth right, is the key. I am convinced myself that Struts has the essential i I'm not sure that in the end a full blown component model for webapp is necessary. Do we really need to start/stop/reload webapp contributions? Is it even possible to reload a contribution without bouncing the webapp. Maybe, I don't know. Yes, it is. There are requirements. (1) clients must not reference the type that will be dynamically reloaded, if they do, either they will implicity load the classes with their class loader or fail to load the classes at all, and these options require shutting down the client (which is what we want to avoid with this design decision); (2) clients can never use a reference to an implementation type, but must always reference a base class or an interface type (there is no way to avoid shutting down the client if you want to change the interface or the base class that is referenced, but this would require the client to be rewritten anyway, so there is no real penalty); (3) the implementation must be able to find the same version of the interface that the client is using, or, in other words, the implementation's classloader must delegate to the client's classloader (easily done by having clients loaded with the system classloader). New implementations can use old implemenations as a template, thereby maintaining state. This has two requirements. (A) the client must make the state of the original object available to factory class that serves the implementations so that the new version can be correctly instantiated; (B) the client must drop all references to the old version to drop the old version and to use the new one (easily done by using the same variable), which Halloway shows as a single line of code in his example: pt = PointFactory.createPoint(pt);. Most of the light weight containers don't bother with hotdeployment and instead focus on the IOC/Dependancy Injection. Perhaps, this would be a good place to start? The focus on IoC or Dependency Injection is perfect, I think (http://www.martinfowler.com/articles/injection.html). My driving philosophy is this: don't create a single dependency that is not necessary. So, for example, if possible, the kernel should provide for development in different flavors of Dependency Injection. I would tend to favor the interface flavor. But, there are reasons to do things differently. I'm tempted to send an email to one of the eclipse lists and see what they think. Sounds good. Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: An Eclipse Like WebApp Framework? -- a proposal
http://struts.apache.org/roadmap.html http://wiki.apache.org/struts/StrutsJericho Seem like pretty significant potential changes to me. I think the problem is that the way struts is currently proposed to change is not the way that you (and some others) want it to. This is why you must stop talking about it and start doing it in my opinion. Even the proposed struts 2.0 stuff may not happen soon, as some of the committers are happy as it is and/or moved on and/or too busy. (Quoting Ted Husted...unless some young turk comes along and cranks out a working codebase over a holiday weekend) If you want your prpopsal to remain struts, setup a wiki whiteboard for a while to get ideas, then code it and submit it to contrib like was done with the Jericho idea. It may take off that way and become struts 2.0, you never know. I don't think I am (or anybody else is) being sensitive to CHANGING struts. I think the problem is (and no offense intended here) that you come off extremely abrasive in your emails, and we are sensitive to that. Your phrasing of without ego in the core came off as extremely confrontational on a personal level. That is what I took offense to. Change struts all you want though, make it better, make it smaller, make it make me dinner. That I am not sensitive to at all. I think most everybody in the community would agree. Matt Michael McGrady wrote: Thanks for your ideas, Matt. Some thoughts on this, relating the personal issues as much to Struts as possible, follow: The subtitle of eXtreme Programming eXplained is EMBRACE CHANGE by Kent Beck. This is all I am saying. Struts as it looks to v3.0 should embrace change as potential, which will increase, not decrease, the community. This means, to me, embrace the possibility of change. This means, to me, components and whittling things that are UNchangeable down rather than up. If you build dependency into a core, you build ego there as well. That is all I am saying. I hope that is considered to be a constructive point. If not, why not? This has been a generic point about scientific and professional community development at least since the 1970s. This has nothing to do with any Struts committers or users in particular, although Struts is not immune to the process which the issues address. I am thinking, for example, in addition to the related movements in programming and computer science about books like Kuhn's The Sources of Scientific Revolution and the Popperian (Karl Popper) idea of falsification as a root or core idea in intellectual and professional development. I really cannot believe how sensitive people on this list are to this sort of thing. I really have no interest in these personal issues. I do think that when people take comments about core issues to be personal, then that is not my problem. I mean, do people read Freud and take his comments about sexuality personally? I don't think so. The core issues in programming development have human issues in them. So, when we talk about component development and kernels and so on, there are human issues. This includes ego. This does not mean I am saying anything about the ego of Struts developers. I am not. I am saying that dependency at the core will encourage personal rather than Struts oriented commentary and goals. That is a point about software development. I too believe in doing rather than talking. I have a lot of code that does what I am talking about. You know, I assume, about the coding I have done on buttons. At this point, however, I am more interested in thinking about it. Again, measure twice, cut once. However, I am not a committee type guy either and I acknowledge that you can talk something to death. I do think that the breadth of my knowledge is probably less than needed to make great decisions about a core like this. I do think that I personally would need the input of more knowledge and experience than I have. But, I love the idea and would work on it. I also love Struts and have no issues with the people. If they have issues, and some do, that is not my business. Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: An Eclipse Like WebApp Framework? -- a proposal
Fundamentally coding changes, I think, refect human needs as much as technical needs. Even good old procedural programming, which many college computer science advocates cannot let go of, had, I think, as its main difficulty the inability of a community to effectively code with it. So, many ostensibly pure theoretical issues, such as data encapsulation, are really attempts to save us from inadvertent (or advertent?) human limitations. I am grateful for Struts and the community of users and developers. Most of the people on here I find more than personally and professionally acceptable, including those that are constantly carping at me with non-Struts related issues which sometimes are so tangential to anything that I am amazed they could care, and even admirable. I do think that we have to acknowledge that at root the issues we are dealing with are not unrelated to egos and we /necessarily /have them in Struts too. I am not against ego. I am for directing it with mindful design decisions. I too think the changes planned for Struts are significant. Michael McGrady Matt Bathje wrote: http://struts.apache.org/roadmap.html http://wiki.apache.org/struts/StrutsJericho Seem like pretty significant potential changes to me. I think the problem is that the way struts is currently proposed to change is not the way that you (and some others) want it to. This is why you must stop talking about it and start doing it in my opinion. Even the proposed struts 2.0 stuff may not happen soon, as some of the committers are happy as it is and/or moved on and/or too busy. (Quoting Ted Husted...unless some young turk comes along and cranks out a working codebase over a holiday weekend) If you want your prpopsal to remain struts, setup a wiki whiteboard for a while to get ideas, then code it and submit it to contrib like was done with the Jericho idea. It may take off that way and become struts 2.0, you never know. I don't think I am (or anybody else is) being sensitive to CHANGING struts. I think the problem is (and no offense intended here) that you come off extremely abrasive in your emails, and we are sensitive to that. Your phrasing of without ego in the core came off as extremely confrontational on a personal level. That is what I took offense to. Change struts all you want though, make it better, make it smaller, make it make me dinner. That I am not sensitive to at all. I think most everybody in the community would agree. Matt Michael McGrady wrote: Thanks for your ideas, Matt. Some thoughts on this, relating the personal issues as much to Struts as possible, follow: The subtitle of eXtreme Programming eXplained is EMBRACE CHANGE by Kent Beck. This is all I am saying. Struts as it looks to v3.0 should embrace change as potential, which will increase, not decrease, the community. This means, to me, embrace the possibility of change. This means, to me, components and whittling things that are UNchangeable down rather than up. If you build dependency into a core, you build ego there as well. That is all I am saying. I hope that is considered to be a constructive point. If not, why not? This has been a generic point about scientific and professional community development at least since the 1970s. This has nothing to do with any Struts committers or users in particular, although Struts is not immune to the process which the issues address. I am thinking, for example, in addition to the related movements in programming and computer science about books like Kuhn's The Sources of Scientific Revolution and the Popperian (Karl Popper) idea of falsification as a root or core idea in intellectual and professional development. I really cannot believe how sensitive people on this list are to this sort of thing. I really have no interest in these personal issues. I do think that when people take comments about core issues to be personal, then that is not my problem. I mean, do people read Freud and take his comments about sexuality personally? I don't think so. The core issues in programming development have human issues in them. So, when we talk about component development and kernels and so on, there are human issues. This includes ego. This does not mean I am saying anything about the ego of Struts developers. I am not. I am saying that dependency at the core will encourage personal rather than Struts oriented commentary and goals. That is a point about software development. I too believe in doing rather than talking. I have a lot of code that does what I am talking about. You know, I assume, about the coding I have done on buttons. At this point, however, I am more interested in thinking about it. Again, measure twice, cut once. However, I am not a committee type guy either and I acknowledge that you can talk something to death. I do think that the breadth of my knowledge is probably less than needed to make great decisions
Re: An Eclipse Like WebApp Framework? -- a proposal
Rob Evans [EMAIL PROTECTED] wrote: Can you point me to a how-to doc so I can get a feel for what JSR-168 has to offer? There's a link to download a PDF containing a few sample chapters from a book on developing JSR-168 portlets within the following article... http://www.theserverside.com/articles/article.tss?l=BuildingPortals ...and the source code included in this book can be downloaded from... http://www.apress.com/book/bookDisplay.html?bID=362 Scott On Wed, 6 Oct 2004 10:04:37 -0700 (PDT), Scott Anderson [EMAIL PROTECTED] wrote: PROPOSAL/SUGGESTION I was a big fan of the component software model advocated by a technology called OpenDoc developed by Apple, IBM, and Novell back in the mid 90's... http://en.wikipedia.org/wiki/OpenDoc Ironically, Steve Jobs killed off this technology because the thought was that Java Beans would be a better solution. This has not happened...yet. This is probably because Sun did a lousy job of evangelizing the potential of technologies like the bean box and others in the Glasgow suite of Java Bean technologies. When I started doing web development I naturally started looking for a similar software model and framework that I could apply to this space. I believe my wait is finally over and the answer is portlets... http://portals.apache.org/ Think of a portal as simply a collection of compound documents made up of portlets and I think you will see how I got here from there. Even though this technology is in its infancy, I believe that there has already been some movement in the Struts community to provide support for JSR-168 an upcoming release. I will be doing all that I can to ensure that this effort is successful. Before anyone starts a new Struts branch, before doing so I urge them to evaluate supporting the development of standardized Struts portlets. In regards to establishing an IDE for this technology, I would think that a portal for developing, or simply assembing, portlets would be a natural solution. Scott ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Eclipse Like WebApp Framework? -- a proposal
You might also want to see: http://struts.apache.org/roadmap.html http://wiki.apache.org/struts/StrutsJericho Portlets are part of the planning for Struts. Michael McGrady Scott Anderson wrote: Rob Evans [EMAIL PROTECTED] wrote: Can you point me to a how-to doc so I can get a feel for what JSR-168 has to offer? There's a link to download a PDF containing a few sample chapters from a book on developing JSR-168 portlets within the following article... http://www.theserverside.com/articles/article.tss?l=BuildingPortals ...and the source code included in this book can be downloaded from... http://www.apress.com/book/bookDisplay.html?bID=362 Scott On Wed, 6 Oct 2004 10:04:37 -0700 (PDT), Scott Anderson [EMAIL PROTECTED] wrote: PROPOSAL/SUGGESTION I was a big fan of the component software model advocated by a technology called OpenDoc developed by Apple, IBM, and Novell back in the mid 90's... http://en.wikipedia.org/wiki/OpenDoc Ironically, Steve Jobs killed off this technology because the thought was that Java Beans would be a better solution. This has not happened...yet. This is probably because Sun did a lousy job of evangelizing the potential of technologies like the bean box and others in the Glasgow suite of Java Bean technologies. When I started doing web development I naturally started looking for a similar software model and framework that I could apply to this space. I believe my wait is finally over and the answer is portlets... http://portals.apache.org/ Think of a portal as simply a collection of compound documents made up of portlets and I think you will see how I got here from there. Even though this technology is in its infancy, I believe that there has already been some movement in the Struts community to provide support for JSR-168 an upcoming release. I will be doing all that I can to ensure that this effort is successful. Before anyone starts a new Struts branch, before doing so I urge them to evaluate supporting the development of standardized Struts portlets. In regards to establishing an IDE for this technology, I would think that a portal for developing, or simply assembing, portlets would be a natural solution. Scott ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
