RE: XMLForms vs Struts
Steven has moved it to Links'. Thank you - I overlooked the already existing point at the links page. Regards, Reinhard Ivelin, I created a new main point in the left menu and called it Cocoon compared. Reinhard -Original Message- From: Ivelin Ivanov [mailto:ivelin;apache.org] Sent: Saturday, November 02, 2002 5:23 PM To: [EMAIL PROTECTED] Subject: Re: XMLForms vs Struts Please do. Wiki is great, but I am not sure in which section would this one article go. Please let me know where it went. Thank you, Ivelin - Original Message - From: Reinhard Poetz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 31, 2002 8:02 AM Subject: RE: XMLForms vs Struts Ivelin, As this is an often discussed question: Do you mind adding it to the CocoonWiki? If no I could do it for you ... Regards, Reinhard -Original Message- From: Ivelin Ivanov [mailto:ivelin;apache.org] Sent: Thursday, October 31, 2002 2:52 PM To: [EMAIL PROTECTED] Subject: Re: XMLForms vs Struts I hope this will not make things even more confusing for you, but here is my view: Struts is 3 parts: 1) An URL map, matching URLs to Actions. Everything you can do with struts-config.xml (Struts), you can do with sitemap.xmap (Cocoon). 2) Custom JSP tags for rendering HTML, like i18n, access to JavaBean properties and others. Cocoon's set of transformers is a superset of Strut's visual tags. 3) Form handling. Automated binding between HTML input fields and JavaBeans. Cocoon's XMLForm does that and much more. It not only provides the binding, but it does it in a browser independent way. Struts is only designed to handle automatically HTML input. For fairness sake, I will tell you that over the last 2 years I have used Struts successfully in big enterprise projects. It is a good and sound technology when you are only interested to support the major HTML browsers and you are not concerned with other interfaces to your application like WML, VXML, Web Services, etc. My recommendation is, if you are in a hurry and you don't want to invest time in learning a new technology, go Struts. If you plan to build a lot of web applications in the future, you must learn Cocoon. It will add a very powerful weapon to your software tools arsenal. You don't have to use it all the time, but when things start to look dangerously complex, you will find it to be a life saver. Best, Ivelin - Original Message - From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 31, 2002 3:48 AM Subject: Re: XMLForms vs Struts Hy; First let me tell you: I like the idea of merging cocoon and struts, because i see both technologies to be helpfull also in conjunction... Omar Tazi wrote: If you like the MVC aspect in Struts and like the flexibility provided by XML/XSLT, and don't like the limitations that come with JSPs, check out our Framework. It's called OXF (Open XML Framework). OXF is the result of our combined passion for Cocoon and Struts/J2EE and our involvement in huge enterprise projects. It will dramatically help you in your tasks (listed below). Good luck! But i am also a bit confused. I'm following the discussons in this mailing list for about a week now and this is already the second mentioning of a product/component (whatever) that claims to be an on top of cocoon development. But when i enter the pages mentioned above, it is very hard to find the backpointers to cocoon as the base component... Despite that all this stuff sounds very interesting, but i get more and more unshure how to proceed. Some questions rise in my mind: 1.) Why are all such nice and nifty add ons developed all outside of cocoon ? 2.) When i move to such an add on component, how can i enshure to keep up with the releases of cocoon (taking adavantage of the enhancements done there)? 3.) Why can't i find pointers to these add ons from the cocoon pages ? There is sooo many good software around the world and cocoon for me is one of the finest. Why does not all this effort take place at the heart but is cluttered around in several loosely coupled or even uncoupled add on projects ??? And now my final question (to come back to the technical part): Why is it so complicated to use struts and cocoon in parallel? As far as i understand the concepts of cocoon, i can embed JSP's in it's workflow, and if a jsp itself uses struts, why not??? Although i haven't tried yet, for me these things seem to be coexisting without problems ... Any enlightments on these points are happily welcome... best regards, Hussayn -- Dr. Hussayn Dabbous
Re: XMLForms vs Struts
Reinhard Poetz wrote: Ivelin, I created a new main point in the left menu and called it Cocoon compared. wiki-polizei In order to keep the left Wiki menu as small as possible, I 'moved' the comparison page (which I like) underneath 'Links' /wiki-polizei Hope you don't mind... /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLForms vs Struts
[EMAIL PROTECTED] wrote: Steven has moved it to Links'. Thank you - I overlooked the already existing point at the links page. oops - you found out already ;-) /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XMLForms vs Struts
Ivelin, I created a new main point in the left menu and called it Cocoon compared. Reinhard -Original Message- From: Ivelin Ivanov [mailto:ivelin;apache.org] Sent: Saturday, November 02, 2002 5:23 PM To: [EMAIL PROTECTED] Subject: Re: XMLForms vs Struts Please do. Wiki is great, but I am not sure in which section would this one article go. Please let me know where it went. Thank you, Ivelin - Original Message - From: Reinhard Poetz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 31, 2002 8:02 AM Subject: RE: XMLForms vs Struts Ivelin, As this is an often discussed question: Do you mind adding it to the CocoonWiki? If no I could do it for you ... Regards, Reinhard -Original Message- From: Ivelin Ivanov [mailto:ivelin;apache.org] Sent: Thursday, October 31, 2002 2:52 PM To: [EMAIL PROTECTED] Subject: Re: XMLForms vs Struts I hope this will not make things even more confusing for you, but here is my view: Struts is 3 parts: 1) An URL map, matching URLs to Actions. Everything you can do with struts-config.xml (Struts), you can do with sitemap.xmap (Cocoon). 2) Custom JSP tags for rendering HTML, like i18n, access to JavaBean properties and others. Cocoon's set of transformers is a superset of Strut's visual tags. 3) Form handling. Automated binding between HTML input fields and JavaBeans. Cocoon's XMLForm does that and much more. It not only provides the binding, but it does it in a browser independent way. Struts is only designed to handle automatically HTML input. For fairness sake, I will tell you that over the last 2 years I have used Struts successfully in big enterprise projects. It is a good and sound technology when you are only interested to support the major HTML browsers and you are not concerned with other interfaces to your application like WML, VXML, Web Services, etc. My recommendation is, if you are in a hurry and you don't want to invest time in learning a new technology, go Struts. If you plan to build a lot of web applications in the future, you must learn Cocoon. It will add a very powerful weapon to your software tools arsenal. You don't have to use it all the time, but when things start to look dangerously complex, you will find it to be a life saver. Best, Ivelin - Original Message - From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 31, 2002 3:48 AM Subject: Re: XMLForms vs Struts Hy; First let me tell you: I like the idea of merging cocoon and struts, because i see both technologies to be helpfull also in conjunction... Omar Tazi wrote: If you like the MVC aspect in Struts and like the flexibility provided by XML/XSLT, and don't like the limitations that come with JSPs, check out our Framework. It's called OXF (Open XML Framework). OXF is the result of our combined passion for Cocoon and Struts/J2EE and our involvement in huge enterprise projects. It will dramatically help you in your tasks (listed below). Good luck! But i am also a bit confused. I'm following the discussons in this mailing list for about a week now and this is already the second mentioning of a product/component (whatever) that claims to be an on top of cocoon development. But when i enter the pages mentioned above, it is very hard to find the backpointers to cocoon as the base component... Despite that all this stuff sounds very interesting, but i get more and more unshure how to proceed. Some questions rise in my mind: 1.) Why are all such nice and nifty add ons developed all outside of cocoon ? 2.) When i move to such an add on component, how can i enshure to keep up with the releases of cocoon (taking adavantage of the enhancements done there)? 3.) Why can't i find pointers to these add ons from the cocoon pages ? There is sooo many good software around the world and cocoon for me is one of the finest. Why does not all this effort take place at the heart but is cluttered around in several loosely coupled or even uncoupled add on projects ??? And now my final question (to come back to the technical part): Why is it so complicated to use struts and cocoon in parallel? As far as i understand the concepts of cocoon, i can embed JSP's in it's workflow, and if a jsp itself uses struts, why not??? Although i haven't tried yet, for me these things seem to be coexisting without problems ... Any enlightments on these points are happily welcome... best regards, Hussayn -- Dr. Hussayn Dabbous SAXESS Software Design GmbH Neuenhöfer Allee 125 50935 Köln Telefon: +49-221-56011-0 Fax: +49-221-56011-20 E-Mail: [EMAIL PROTECTED] - Please check that your question has not already
Re: XMLForms vs Struts
Please do. Wiki is great, but I am not sure in which section would this one article go. Please let me know where it went. Thank you, Ivelin - Original Message - From: Reinhard Poetz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 31, 2002 8:02 AM Subject: RE: XMLForms vs Struts Ivelin, As this is an often discussed question: Do you mind adding it to the CocoonWiki? If no I could do it for you ... Regards, Reinhard -Original Message- From: Ivelin Ivanov [mailto:ivelin;apache.org] Sent: Thursday, October 31, 2002 2:52 PM To: [EMAIL PROTECTED] Subject: Re: XMLForms vs Struts I hope this will not make things even more confusing for you, but here is my view: Struts is 3 parts: 1) An URL map, matching URLs to Actions. Everything you can do with struts-config.xml (Struts), you can do with sitemap.xmap (Cocoon). 2) Custom JSP tags for rendering HTML, like i18n, access to JavaBean properties and others. Cocoon's set of transformers is a superset of Strut's visual tags. 3) Form handling. Automated binding between HTML input fields and JavaBeans. Cocoon's XMLForm does that and much more. It not only provides the binding, but it does it in a browser independent way. Struts is only designed to handle automatically HTML input. For fairness sake, I will tell you that over the last 2 years I have used Struts successfully in big enterprise projects. It is a good and sound technology when you are only interested to support the major HTML browsers and you are not concerned with other interfaces to your application like WML, VXML, Web Services, etc. My recommendation is, if you are in a hurry and you don't want to invest time in learning a new technology, go Struts. If you plan to build a lot of web applications in the future, you must learn Cocoon. It will add a very powerful weapon to your software tools arsenal. You don't have to use it all the time, but when things start to look dangerously complex, you will find it to be a life saver. Best, Ivelin - Original Message - From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 31, 2002 3:48 AM Subject: Re: XMLForms vs Struts Hy; First let me tell you: I like the idea of merging cocoon and struts, because i see both technologies to be helpfull also in conjunction... Omar Tazi wrote: If you like the MVC aspect in Struts and like the flexibility provided by XML/XSLT, and don't like the limitations that come with JSPs, check out our Framework. It's called OXF (Open XML Framework). OXF is the result of our combined passion for Cocoon and Struts/J2EE and our involvement in huge enterprise projects. It will dramatically help you in your tasks (listed below). Good luck! But i am also a bit confused. I'm following the discussons in this mailing list for about a week now and this is already the second mentioning of a product/component (whatever) that claims to be an on top of cocoon development. But when i enter the pages mentioned above, it is very hard to find the backpointers to cocoon as the base component... Despite that all this stuff sounds very interesting, but i get more and more unshure how to proceed. Some questions rise in my mind: 1.) Why are all such nice and nifty add ons developed all outside of cocoon ? 2.) When i move to such an add on component, how can i enshure to keep up with the releases of cocoon (taking adavantage of the enhancements done there)? 3.) Why can't i find pointers to these add ons from the cocoon pages ? There is sooo many good software around the world and cocoon for me is one of the finest. Why does not all this effort take place at the heart but is cluttered around in several loosely coupled or even uncoupled add on projects ??? And now my final question (to come back to the technical part): Why is it so complicated to use struts and cocoon in parallel? As far as i understand the concepts of cocoon, i can embed JSP's in it's workflow, and if a jsp itself uses struts, why not??? Although i haven't tried yet, for me these things seem to be coexisting without problems ... Any enlightments on these points are happily welcome... best regards, Hussayn -- Dr. Hussayn Dabbous SAXESS Software Design GmbH Neuenhöfer Allee 125 50935 Köln Telefon: +49-221-56011-0 Fax: +49-221-56011-20 E-Mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
Re: XMLForms vs Struts
Hy; First let me tell you: I like the idea of merging cocoon and struts, because i see both technologies to be helpfull also in conjunction... Omar Tazi wrote: If you like the MVC aspect in Struts and like the flexibility provided by XML/XSLT, and don't like the limitations that come with JSPs, check out our Framework. It's called OXF (Open XML Framework). OXF is the result of our combined passion for Cocoon and Struts/J2EE and our involvement in huge enterprise projects. It will dramatically help you in your tasks (listed below). Good luck! But i am also a bit confused. I'm following the discussons in this mailing list for about a week now and this is already the second mentioning of a product/component (whatever) that claims to be an on top of cocoon development. But when i enter the pages mentioned above, it is very hard to find the backpointers to cocoon as the base component... Despite that all this stuff sounds very interesting, but i get more and more unshure how to proceed. Some questions rise in my mind: 1.) Why are all such nice and nifty add ons developed all outside of cocoon ? 2.) When i move to such an add on component, how can i enshure to keep up with the releases of cocoon (taking adavantage of the enhancements done there)? 3.) Why can't i find pointers to these add ons from the cocoon pages ? There is sooo many good software around the world and cocoon for me is one of the finest. Why does not all this effort take place at the heart but is cluttered around in several loosely coupled or even uncoupled add on projects ??? And now my final question (to come back to the technical part): Why is it so complicated to use struts and cocoon in parallel? As far as i understand the concepts of cocoon, i can embed JSP's in it's workflow, and if a jsp itself uses struts, why not??? Although i haven't tried yet, for me these things seem to be coexisting without problems ... Any enlightments on these points are happily welcome... best regards, Hussayn -- Dr. Hussayn Dabbous SAXESS Software Design GmbH Neuenhöfer Allee 125 50935 Köln Telefon: +49-221-56011-0 Fax: +49-221-56011-20 E-Mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLForms vs Struts
I hope this will not make things even more confusing for you, but here is my view: Struts is 3 parts: 1) An URL map, matching URLs to Actions. Everything you can do with struts-config.xml (Struts), you can do with sitemap.xmap (Cocoon). 2) Custom JSP tags for rendering HTML, like i18n, access to JavaBean properties and others. Cocoon's set of transformers is a superset of Strut's visual tags. 3) Form handling. Automated binding between HTML input fields and JavaBeans. Cocoon's XMLForm does that and much more. It not only provides the binding, but it does it in a browser independent way. Struts is only designed to handle automatically HTML input. For fairness sake, I will tell you that over the last 2 years I have used Struts successfully in big enterprise projects. It is a good and sound technology when you are only interested to support the major HTML browsers and you are not concerned with other interfaces to your application like WML, VXML, Web Services, etc. My recommendation is, if you are in a hurry and you don't want to invest time in learning a new technology, go Struts. If you plan to build a lot of web applications in the future, you must learn Cocoon. It will add a very powerful weapon to your software tools arsenal. You don't have to use it all the time, but when things start to look dangerously complex, you will find it to be a life saver. Best, Ivelin - Original Message - From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 31, 2002 3:48 AM Subject: Re: XMLForms vs Struts Hy; First let me tell you: I like the idea of merging cocoon and struts, because i see both technologies to be helpfull also in conjunction... Omar Tazi wrote: If you like the MVC aspect in Struts and like the flexibility provided by XML/XSLT, and don't like the limitations that come with JSPs, check out our Framework. It's called OXF (Open XML Framework). OXF is the result of our combined passion for Cocoon and Struts/J2EE and our involvement in huge enterprise projects. It will dramatically help you in your tasks (listed below). Good luck! But i am also a bit confused. I'm following the discussons in this mailing list for about a week now and this is already the second mentioning of a product/component (whatever) that claims to be an on top of cocoon development. But when i enter the pages mentioned above, it is very hard to find the backpointers to cocoon as the base component... Despite that all this stuff sounds very interesting, but i get more and more unshure how to proceed. Some questions rise in my mind: 1.) Why are all such nice and nifty add ons developed all outside of cocoon ? 2.) When i move to such an add on component, how can i enshure to keep up with the releases of cocoon (taking adavantage of the enhancements done there)? 3.) Why can't i find pointers to these add ons from the cocoon pages ? There is sooo many good software around the world and cocoon for me is one of the finest. Why does not all this effort take place at the heart but is cluttered around in several loosely coupled or even uncoupled add on projects ??? And now my final question (to come back to the technical part): Why is it so complicated to use struts and cocoon in parallel? As far as i understand the concepts of cocoon, i can embed JSP's in it's workflow, and if a jsp itself uses struts, why not??? Although i haven't tried yet, for me these things seem to be coexisting without problems ... Any enlightments on these points are happily welcome... best regards, Hussayn -- Dr. Hussayn Dabbous SAXESS Software Design GmbH Neuenhöfer Allee 125 50935 Köln Telefon: +49-221-56011-0 Fax: +49-221-56011-20 E-Mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XMLForms vs Struts
Ivelin, As this is an often discussed question: Do you mind adding it to the CocoonWiki? If no I could do it for you ... Regards, Reinhard -Original Message- From: Ivelin Ivanov [mailto:ivelin;apache.org] Sent: Thursday, October 31, 2002 2:52 PM To: [EMAIL PROTECTED] Subject: Re: XMLForms vs Struts I hope this will not make things even more confusing for you, but here is my view: Struts is 3 parts: 1) An URL map, matching URLs to Actions. Everything you can do with struts-config.xml (Struts), you can do with sitemap.xmap (Cocoon). 2) Custom JSP tags for rendering HTML, like i18n, access to JavaBean properties and others. Cocoon's set of transformers is a superset of Strut's visual tags. 3) Form handling. Automated binding between HTML input fields and JavaBeans. Cocoon's XMLForm does that and much more. It not only provides the binding, but it does it in a browser independent way. Struts is only designed to handle automatically HTML input. For fairness sake, I will tell you that over the last 2 years I have used Struts successfully in big enterprise projects. It is a good and sound technology when you are only interested to support the major HTML browsers and you are not concerned with other interfaces to your application like WML, VXML, Web Services, etc. My recommendation is, if you are in a hurry and you don't want to invest time in learning a new technology, go Struts. If you plan to build a lot of web applications in the future, you must learn Cocoon. It will add a very powerful weapon to your software tools arsenal. You don't have to use it all the time, but when things start to look dangerously complex, you will find it to be a life saver. Best, Ivelin - Original Message - From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 31, 2002 3:48 AM Subject: Re: XMLForms vs Struts Hy; First let me tell you: I like the idea of merging cocoon and struts, because i see both technologies to be helpfull also in conjunction... Omar Tazi wrote: If you like the MVC aspect in Struts and like the flexibility provided by XML/XSLT, and don't like the limitations that come with JSPs, check out our Framework. It's called OXF (Open XML Framework). OXF is the result of our combined passion for Cocoon and Struts/J2EE and our involvement in huge enterprise projects. It will dramatically help you in your tasks (listed below). Good luck! But i am also a bit confused. I'm following the discussons in this mailing list for about a week now and this is already the second mentioning of a product/component (whatever) that claims to be an on top of cocoon development. But when i enter the pages mentioned above, it is very hard to find the backpointers to cocoon as the base component... Despite that all this stuff sounds very interesting, but i get more and more unshure how to proceed. Some questions rise in my mind: 1.) Why are all such nice and nifty add ons developed all outside of cocoon ? 2.) When i move to such an add on component, how can i enshure to keep up with the releases of cocoon (taking adavantage of the enhancements done there)? 3.) Why can't i find pointers to these add ons from the cocoon pages ? There is sooo many good software around the world and cocoon for me is one of the finest. Why does not all this effort take place at the heart but is cluttered around in several loosely coupled or even uncoupled add on projects ??? And now my final question (to come back to the technical part): Why is it so complicated to use struts and cocoon in parallel? As far as i understand the concepts of cocoon, i can embed JSP's in it's workflow, and if a jsp itself uses struts, why not??? Although i haven't tried yet, for me these things seem to be coexisting without problems ... Any enlightments on these points are happily welcome... best regards, Hussayn -- Dr. Hussayn Dabbous SAXESS Software Design GmbH Neuenhöfer Allee 125 50935 Köln Telefon: +49-221-56011-0 Fax: +49-221-56011-20 E-Mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
Re: XMLForms vs Struts
Ivelin wrote: 3) Form handling. Automated binding between HTML input fields and JavaBeans. Cocoon's XMLForm does that and much more. It not only provides the binding, but it does it in a browser independent way. Struts is only designed to handle automatically HTML input. This is a very smart summary of diferences between XMLForms Struts. Thanks to all for your advice. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLForms vs Struts
SAXESS - Hussayn Dabbous wrote: But i am also a bit confused. I'm following the discussons in this mailing list for about a week now and this is already the second mentioning of a product/component (whatever) that claims to be an on top of cocoon development. But when i enter the pages mentioned above, it is very hard to find the backpointers to cocoon as the base component... Hussayn, in this particular case the explanation is that OXF compares with Cocoon on a conceptual level, but doesn't actually use any code from Cocoon. It is a completely separate project based on a different architecture of XML pipelines. To tell you the truth, OXF was partly born from frustrations that its authors had with Cocoon. I hope this clears up the confusion. And now my final question (to come back to the technical part): Why is it so complicated to use struts and cocoon in parallel? As far as i understand the concepts of cocoon, i can embed JSP's in it's workflow, and if a jsp itself uses struts, why not??? Although i haven't tried yet, for me these things seem to be coexisting without problems ... I don't see why this would not be possible (at least in theory) to do it this way. Usually, from a Struts action you forward your request to a JSP, but it is actually possible to forward it to any servlet (this is often how people hook up XSLT with Struts). Such a servlet could be the Cocoon servlet. You would probably need to have the Struts JAR and all the Cocoon JARs in the same web application, and to create a servlet mapping that maps some URLs to the Struts controller. From Cocoon, you would serialize to XML the JavaBeans put in the request and session from Struts and from there perform further processing. I don't know if anybody has attempted this so far though. Hope this helps, -Erik - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XMLForms vs Struts
I'm beginning to design a small system for my company and I need some forms to input/output data. How small? Given that you are posting on Cocoon-users I assume you are considering using Cocoon though you don't specifically mention it. The general consensus seems to be that Cocoon isn't really suited for small sites/systems. However, if you have a lot of dynamic rendering, or multiple browser issues (egg. graceful degradation of multimedia), or multiple output format requirements it still might make sense. I wanto to use open software for the project. I read about frameworks like struts, xmlforms and perhaps others. However, I don't know how to decide the technology to use. Since XMLForms and Struts aren't directly comparable (they work at very different levels and do very different things) we really need to know more about your requirements: How many users? How many pages? How many forms? If you can't give us high level requirements how about low level requirements: Do you need database support? Do you need EJB support? Do you need XML support? Do you need Web services support? Do you need LDAP support? Recommending a particular web technology implementation without having specific requirements is sort of like recommending a vehicle without knowing whether the person really has requirements for a car, truck, train, airplane or boat... - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XMLForms vs Struts
I'm sorry. It's a kind of help desk in our intranet where the users can: 1) Request technical assistance (input) 2) Query the status of their previous requests 3) Query a DB where any user can look at common problems/solutions We have 500 total users. I think there could be 10/20 users (max) using the app simultaneously. We are not planning to use EJB, WS or LDAP. We have been considering to use a relational DB (Oracle). There are commercial applications for this very purpose, so I'm not sure why you're looking at building this yourself? However, given that you are, I'd guess you have no need for multiple language support, no need for eventually scaling the thing to support a lot of users, and no need for multiple browser support. As such, Cocoon is likely overkill. It's not even clear that you need much of a flexible controller structure (any dynamic work flow?), but Struts won't do you any harm. Otherwise this could just be a simple JSP site or just HTML with Servlets... If you have control over the browser you might want to look at DHTML or client side XML/XSLT with CSS just to keep presentation separated a little better. Personally, I'd likely go with a client side XML/XSLT and Servlet implementation, but I don't know if your shop can handle the XSLT authoring (it's a bit of a paradigm shift from Java coding)? I also don't know what other infrastructure I'd add to the mix without knowing the requirements better. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLForms vs Struts
If you like the MVC aspect in Struts and like the flexibility provided by XML/XSLT, and don't like the limitations that come with JSPs, check out our Framework. It's called OXF (Open XML Framework). OXF is the result of our combined passion for Cocoon and Struts/J2EE and our involvement in huge enterprise projects. It will dramatically help you in your tasks (listed below). Good luck! http://www.orbeon.com/oxf/ -Omar Hunsberger, Peter wrote: I'm sorry. It's a kind of help desk in our intranet where the users can: 1) Request technical assistance (input) 2) Query the status of their previous requests 3) Query a DB where any user can look at common problems/solutions We have 500 total users. I think there could be 10/20 users (max) using the app simultaneously. We are not planning to use EJB, WS or LDAP. We have been considering to use a relational DB (Oracle). There are commercial applications for this very purpose, so I'm not sure why you're looking at building this yourself? However, given that you are, I'd guess you have no need for multiple language support, no need for eventually scaling the thing to support a lot of users, and no need for multiple browser support. As such, Cocoon is likely overkill. It's not even clear that you need much of a flexible controller structure (any dynamic work flow?), but Struts won't do you any harm. Otherwise this could just be a simple JSP site or just HTML with Servlets... If you have control over the browser you might want to look at DHTML or client side XML/XSLT with CSS just to keep presentation separated a little better. Personally, I'd likely go with a client side XML/XSLT and Servlet implementation, but I don't know if your shop can handle the XSLT authoring (it's a bit of a paradigm shift from Java coding)? I also don't know what other infrastructure I'd add to the mix without knowing the requirements better. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLForms vs Struts
Struts is certainly more mature. XMLForm has a lot of technological advantages, but it will not be released until Cocoon 2.1 stable is out, which is probably end of this year. Ivelin - Original Message - From: Jorge Bello [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 30, 2002 9:18 AM Subject: XMLForms vs Struts May be this a naive question, so please be tolerant. I'm beginning to design a small system for my company and I need some forms to input/output data. I wanto to use open software for the project. I read about frameworks like struts, xmlforms and perhaps others. However, I don't know how to decide the technology to use. One important aspect to consider is maturity of product. Any hint ? TIA - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
