Re: S2 as JSR for Action Framework
Ralf Fischer wrote: Well there is a thing like that where you can publish information to google or other search engines in one single file. You have to serve a file with a name like http://foo.com/site.xml.gz [1] which holds a description of your whole site. Sure it's no API, but it gets pretty close to what you mention. Thanks Ralf, this is actually far better than I'd ever realized. Google I/O has a video on the topic from May 08: http://sites.google.com/site/io/sitemaps-exposing-interactive-and-hidden-content-in-web-applications - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
Musachy Barroso wrote: What are the plans for the future of the REST plugin? Has anybody tried to make it more JSR-311 like? I am not a REST user myself, but I am kind of bored and could help if there was a clear understanding of what needs to be done. I haven't touched the REST plugin for a while but actively use it. I'm pretty happy with it but it needs to be exercised more across broader areas to find remaining problems. I use it for public JSON, public HTML and private machine<->machine services (XML). I support moving in the direction of JSR-311. My two biggest issues with the plugin at the moment are: - a public resoruce that's served as XML would typically reference a schema and/or namespace. This is possible with XStream by writing to the outputstream prior to serialization, but it will often be different for each model. The existing ContentTypeHandler can't readily deal with this binding between model class and schema and it's up to the plugin user to invent their own strategy. Not sure if JSR-311 addresses this., but it could drive an entirely different approach to consuming a resource with different content-types. - exception handling is completely ad hoc (up to the plugin user). I try to get exceptions to fall through to the ExceptionMapper which then invokes another action that generates a response consistent with the requested content type. eg. if they requested XML, they should never get an HTML stacktrace. Not sure if JSR-311 addresses this. The fragility in this area means I'd opt for a dedicated WS/RS library rather than use the plugin for genuinely public resources/services. - and a third: hierarchical URIs (/book/1/chapter/2) require a custom actionmapper, but shouldn't. In general, support for params in the path is a little clunky (and undocumented). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: S2 as JSR for Action Framework
That is pretty much what I had in mind, the only thing is that I would suggest to look at the convention plugin instead, as that is what we will be using, some day. The convention plugin is in then sandbox, drop an email here if you need help finding your way around in the code. musachy On Tue, Aug 26, 2008 at 6:14 PM, Jordi Fernandez <[EMAIL PROTECTED]> wrote: > Hi Musachy, > > I've been using struts 2 with the REST plugin in several projects > and it's been great. It's really nice (thanks for the job, Don!). > I'd like to make the REST plugin more JSR-311 like, too. I've > been studying the struts2 source code for some days, focusing > on the REST and the Codebehind plugin. I've created a new plugin > based on the REST plugin source code + the ClasspathPackageProvider > class from the codebehind plugin. I was thinking in the following > implementation path for initial implementation of a subset of the spec: > > - Process jsr-311 @Path annotation with ClasspathPackageProvider to > configure > namespaces, packages, etc. to match requests to resource methods > - Create jsr-311 interceptors to process @MatrixParam, @QueryParam, > @PathParam, > etc, annotations. > > Am I on the right path? Any advices from the most experienced? > > Thanks in advance. > > Musachy Barroso wrote: >> >> What are the plans for the future of the REST plugin? Has anybody >> tried to make it more JSR-311 like? I am not a REST user myself, but I >> am kind of bored and could help if there was a clear understanding of >> what needs to be done. >> >> musachy >> >> On Mon, Aug 25, 2008 at 12:30 AM, Jeromy Evans >> <[EMAIL PROTECTED]> wrote: >>> >>> Don Brown wrote: On Mon, Aug 25, 2008 at 12:54 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: > Another option is a client-side component-based framework like Ext or > Flex > running directly against web services, RESTful or otherwise. No > server-side > web framework required. Of course, you could use something server-side > like > DWR to facilitate working with web services, or Jersey for RESTful > services, > but that would be a choice rather than a requirement. > This is a nice design, when you can do it. GWT is also a good way to build these types of apps. Unfortunately, they can easily break much of what makes the web what it is - the back button, unique, addressable URI's, accessibility, search engine crawling, etc. Therefore, I think some sort of server-side web framework will usually be necessary, however, I don't think it has to go so far as JSF, where they try to push all the state to the server. I was talking with a guy here at work who is looking to start using GWT more about how and where a plain HTML view of the application fits. He wants to do very dynamic, client-side heavy views, but still needs to support search engines and REST clients. What if you use Jersey for your REST API, GWT or straight JQuery for your client-side UI, then have Jersey + something generate HTML views of your REST API, which you could use for search engines and developers wanting to browse and interact with your application. If you can have the HTML representation of your REST API auto-generated, you wouldn't have to maintain two different interfaces, and you could go fully nuts with your client-side heavy app without having to worry about accessibility or search engine issues. Don >>> >>> [rant] Personally I think search engines need to solve this problem. The >>> era of crawling sites needs to close. As a publisher of content I should >>> be >>> able to connect to a Google API and publish my content and URIs to them >>> in a >>> standard machine-friendly format ready for indexing. Alternatively, I >>> could >>> implement a dedicated-service for them to consume instead of emulating >>> pages >>> of content in a non-page-oriented application. Then my application then >>> can >>> be what it needs to be in any form suitable for my users instead of >>> perpetuating the artificial SEO-optimzation industry. [/rant] >>> >>> Anyway, despite that, I took this approach recently with a client-heavy >>> (single page) application myself, with the exception of autogeneration of >>> the HTML. Basically: >>> - mandated that the client include a custom header (X-RequestedBy) and >>> signature in the request >>> - if headers present, the S2 rest plugin handled the request and returned >>> the resource in the requested content type. I just had to build the view >>> myself for html. >>> - if the header's not present and it was a GET, the REST plugin returned >>> the >>> HTML view and sitemesh decorated it as a full HTML PAGE. >>> - if a resource was requested directly and the user had javascript, they >>> were redirected to the rich client with the best-guess initial state >>> based >>> on the URI >>> - all flow control is managed on the cl
Re: Re: S2 as JSR for Action Framework
Hi Musachy, I've been using struts 2 with the REST plugin in several projects and it's been great. It's really nice (thanks for the job, Don!). I'd like to make the REST plugin more JSR-311 like, too. I've been studying the struts2 source code for some days, focusing on the REST and the Codebehind plugin. I've created a new plugin based on the REST plugin source code + the ClasspathPackageProvider class from the codebehind plugin. I was thinking in the following implementation path for initial implementation of a subset of the spec: - Process jsr-311 @Path annotation with ClasspathPackageProvider to configure namespaces, packages, etc. to match requests to resource methods - Create jsr-311 interceptors to process @MatrixParam, @QueryParam, @PathParam, etc, annotations. Am I on the right path? Any advices from the most experienced? Thanks in advance. Musachy Barroso wrote: What are the plans for the future of the REST plugin? Has anybody tried to make it more JSR-311 like? I am not a REST user myself, but I am kind of bored and could help if there was a clear understanding of what needs to be done. musachy On Mon, Aug 25, 2008 at 12:30 AM, Jeromy Evans <[EMAIL PROTECTED]> wrote: Don Brown wrote: On Mon, Aug 25, 2008 at 12:54 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: Another option is a client-side component-based framework like Ext or Flex running directly against web services, RESTful or otherwise. No server-side web framework required. Of course, you could use something server-side like DWR to facilitate working with web services, or Jersey for RESTful services, but that would be a choice rather than a requirement. This is a nice design, when you can do it. GWT is also a good way to build these types of apps. Unfortunately, they can easily break much of what makes the web what it is - the back button, unique, addressable URI's, accessibility, search engine crawling, etc. Therefore, I think some sort of server-side web framework will usually be necessary, however, I don't think it has to go so far as JSF, where they try to push all the state to the server. I was talking with a guy here at work who is looking to start using GWT more about how and where a plain HTML view of the application fits. He wants to do very dynamic, client-side heavy views, but still needs to support search engines and REST clients. What if you use Jersey for your REST API, GWT or straight JQuery for your client-side UI, then have Jersey + something generate HTML views of your REST API, which you could use for search engines and developers wanting to browse and interact with your application. If you can have the HTML representation of your REST API auto-generated, you wouldn't have to maintain two different interfaces, and you could go fully nuts with your client-side heavy app without having to worry about accessibility or search engine issues. Don [rant] Personally I think search engines need to solve this problem. The era of crawling sites needs to close. As a publisher of content I should be able to connect to a Google API and publish my content and URIs to them in a standard machine-friendly format ready for indexing. Alternatively, I could implement a dedicated-service for them to consume instead of emulating pages of content in a non-page-oriented application. Then my application then can be what it needs to be in any form suitable for my users instead of perpetuating the artificial SEO-optimzation industry. [/rant] Anyway, despite that, I took this approach recently with a client-heavy (single page) application myself, with the exception of autogeneration of the HTML. Basically: - mandated that the client include a custom header (X-RequestedBy) and signature in the request - if headers present, the S2 rest plugin handled the request and returned the resource in the requested content type. I just had to build the view myself for html. - if the header's not present and it was a GET, the REST plugin returned the HTML view and sitemesh decorated it as a full HTML PAGE. - if a resource was requested directly and the user had javascript, they were redirected to the rich client with the best-guess initial state based on the URI - all flow control is managed on the client. That meant that one action could service requests for the resource for rich clients and support search engines requests for the same content. Search engines could browse the site through the same content spread over many little well-formed pages. Users accessing the site via the search engine's sub-URI would see the rich client with appropriate initial state derived from the URI On the client-side sensible URIs could still be used in links and listeners adjusted the content type when appropriate. Users without JS could get by but were a low priority. Users with screen readers are still a challenge but not due to struts. This approach wasn't as simple as it should be though but confirms that Don's idea is feasible. The bigge
Re: S2 as JSR for Action Framework
Adam Hardy wrote: Frank, do you not use the back button? I reckon I use it from around 5 to 50 times a day. Of course I do... Although I can't say how often because that would imply how much surfing the web I'm doing as opposed to actually working and my boss just *might* read this list some day :) I think the paradigm shift is less a shift and more of a paradigm split. Web2 and javascript-based apps have taken their place (after 10 years finally) at the top of the web food chain. What's the best term? Rich client? That might be a fair way to put it, and this is something I've talked extensively about over the past few years... I tend to use the term web SITE vs. web APP... I talk about that in all of my books actually, and the first one is a few years old. Web SITES are fundamentally different animals than web APPS, and I think the rules are a bit different for their development as well. But Web2 hasn't replaced bog-standard HTML as its version number suggests, it complements it, leaving a big space for low-Javascript clients which just use the barest minimum or no javascript. Yep, I don't disagree with that at all. It's obviously only the former websites which need no back-button, and obviously the latter where the back button is very useful. Hehe, we're pretty much saying the same thing I think :) Maybe W3C has already thought of this - I don't know - and we'll see window.disableHistory appear in the DOM (or something similar) Sure... about the same time they get rid of the and tags :) Regards Adam Frank -- Frank W. Zammetti Author of "Practical Dojo Projects" abd "Practical DWR 2 Projects" and "Practical JavaScript, DOM Scripting and Ajax Projects" and "Practical Ajax Projects With Java Technology" (For info: apress.com/book/search?searchterm=zammetti&act=search) My "look ma, I have a blog too!" blog: zammetti.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
Frank W. Zammetti on 25/08/08 05:36, wrote: Don Brown wrote: This is a nice design, when you can do it. GWT is also a good way to build these types of apps. Unfortunately, they can easily break much of what makes the web what it is - the back button, unique, addressable URI's, accessibility, search engine crawling, etc. It's always interesting how often you hear the "this breaks the web" sorts of statements. I'm not arguing the factuality of the statement, I just find it interesting. It's also interesting the way you put it here... you don't say anything like "this breaks the web", nor do you make a value judgment on it (well, I suppose the word "unfortunately" implies a value judgment, but it's not explicit). I think we're at an interesting point in time right now... many people are kind of mentally stuck in the sense that they see the ways in which RIAs (can) break things like the back button and they think "well, that's bad". But, maybe we shouldn't be asking if RIAs are the way to go, but we should instead be asking different questions like "is the back button as a navigational metaphor something we really want to be perpetuating anyway"? It's kind of like if someone came up with a hydrogen-based fuel system for cars but for some reason (work with me here!) you could never use a cell phone in the car or it'd explode... I don't think we shouldn't at that point be asking if the fuel system is the right answer or not, we should be asking whether the limitation it imposes is something that should factor into the decision at all in the first place. Wouldn't we be better off if you couldn't use cell phones in cars anyway?!? Note that I'm not making a value judgment here either necessarily, although I suspect my opinion is fairly obvious :) I do think we're in the midst of a paradigm shift to a large extent, and I think there's some fascinating consequences of that shift. Frank, do you not use the back button? I reckon I use it from around 5 to 50 times a day. I think the paradigm shift is less a shift and more of a paradigm split. Web2 and javascript-based apps have taken their place (after 10 years finally) at the top of the web food chain. What's the best term? Rich client? But Web2 hasn't replaced bog-standard HTML as its version number suggests, it complements it, leaving a big space for low-Javascript clients which just use the barest minimum or no javascript. It's obviously only the former websites which need no back-button, and obviously the latter where the back button is very useful. Maybe W3C has already thought of this - I don't know - and we'll see window.disableHistory appear in the DOM (or something similar) Regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
What are the plans for the future of the REST plugin? Has anybody tried to make it more JSR-311 like? I am not a REST user myself, but I am kind of bored and could help if there was a clear understanding of what needs to be done. musachy On Mon, Aug 25, 2008 at 12:30 AM, Jeromy Evans <[EMAIL PROTECTED]> wrote: > Don Brown wrote: >> >> On Mon, Aug 25, 2008 at 12:54 PM, Martin Cooper <[EMAIL PROTECTED]> >> wrote: >> >>> >>> Another option is a client-side component-based framework like Ext or >>> Flex >>> running directly against web services, RESTful or otherwise. No >>> server-side >>> web framework required. Of course, you could use something server-side >>> like >>> DWR to facilitate working with web services, or Jersey for RESTful >>> services, >>> but that would be a choice rather than a requirement. >>> >> >> This is a nice design, when you can do it. GWT is also a good way to >> build these types of apps. Unfortunately, they can easily break much >> of what makes the web what it is - the back button, unique, >> addressable URI's, accessibility, search engine crawling, etc. >> Therefore, I think some sort of server-side web framework will usually >> be necessary, however, I don't think it has to go so far as JSF, where >> they try to push all the state to the server. I was talking with a >> guy here at work who is looking to start using GWT more about how and >> where a plain HTML view of the application fits. He wants to do very >> dynamic, client-side heavy views, but still needs to support search >> engines and REST clients. What if you use Jersey for your REST API, >> GWT or straight JQuery for your client-side UI, then have Jersey + >> something generate HTML views of your REST API, which you could use >> for search engines and developers wanting to browse and interact with >> your application. If you can have the HTML representation of your >> REST API auto-generated, you wouldn't have to maintain two different >> interfaces, and you could go fully nuts with your client-side heavy >> app without having to worry about accessibility or search engine >> issues. >> >> Don >> >> > > > [rant] Personally I think search engines need to solve this problem. The > era of crawling sites needs to close. As a publisher of content I should be > able to connect to a Google API and publish my content and URIs to them in a > standard machine-friendly format ready for indexing. Alternatively, I could > implement a dedicated-service for them to consume instead of emulating pages > of content in a non-page-oriented application. Then my application then can > be what it needs to be in any form suitable for my users instead of > perpetuating the artificial SEO-optimzation industry. [/rant] > > Anyway, despite that, I took this approach recently with a client-heavy > (single page) application myself, with the exception of autogeneration of > the HTML. Basically: > - mandated that the client include a custom header (X-RequestedBy) and > signature in the request > - if headers present, the S2 rest plugin handled the request and returned > the resource in the requested content type. I just had to build the view > myself for html. > - if the header's not present and it was a GET, the REST plugin returned the > HTML view and sitemesh decorated it as a full HTML PAGE. > - if a resource was requested directly and the user had javascript, they > were redirected to the rich client with the best-guess initial state based > on the URI > - all flow control is managed on the client. > > That meant that one action could service requests for the resource for rich > clients and support search engines requests for the same content. > Search engines could browse the site through the same content spread over > many little well-formed pages. > Users accessing the site via the search engine's sub-URI would see the rich > client with appropriate initial state derived from the URI > On the client-side sensible URIs could still be used in links and listeners > adjusted the content type when appropriate. > > Users without JS could get by but were a low priority. Users with screen > readers are still a challenge but not due to struts. > > This approach wasn't as simple as it should be though but confirms that > Don's idea is feasible. The biggest problem was in fact with IE6 memory > leaks and the poor performance of javascript in most browsers. A flex > client could have used the same services without a problem. If automation > of a bland html view with a sitemap were provided for users without > javascript/flash you'd eliminate the double-up on the views for search > engines. > > I definitely like the direction these discussions are going. > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd
Re: S2 as JSR for Action Framework
Hi, Am 25.08.2008 um 06:30 schrieb Jeromy Evans: Don Brown wrote: On Mon, Aug 25, 2008 at 12:54 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: Another option is a client-side component-based framework like Ext or Flex running directly against web services, RESTful or otherwise. No server-side web framework required. Of course, you could use something server- side like DWR to facilitate working with web services, or Jersey for RESTful services, but that would be a choice rather than a requirement. This is a nice design, when you can do it. GWT is also a good way to build these types of apps. Unfortunately, they can easily break much of what makes the web what it is - the back button, unique, addressable URI's, accessibility, search engine crawling, etc. Therefore, I think some sort of server-side web framework will usually be necessary, however, I don't think it has to go so far as JSF, where they try to push all the state to the server. I was talking with a guy here at work who is looking to start using GWT more about how and where a plain HTML view of the application fits. He wants to do very dynamic, client-side heavy views, but still needs to support search engines and REST clients. What if you use Jersey for your REST API, GWT or straight JQuery for your client-side UI, then have Jersey + something generate HTML views of your REST API, which you could use for search engines and developers wanting to browse and interact with your application. If you can have the HTML representation of your REST API auto-generated, you wouldn't have to maintain two different interfaces, and you could go fully nuts with your client-side heavy app without having to worry about accessibility or search engine issues. Don [rant] Personally I think search engines need to solve this problem. The era of crawling sites needs to close. As a publisher of content I should be able to connect to a Google API and publish my content and URIs to them in a standard machine-friendly format ready for indexing. Alternatively, I could implement a dedicated- service for them to consume instead of emulating pages of content in a non-page-oriented application. Then my application then can be what it needs to be in any form suitable for my users instead of perpetuating the artificial SEO-optimzation industry. [/rant] Well there is a thing like that where you can publish information to google or other search engines in one single file. You have to serve a file with a name like http://foo.com/site.xml.gz [1] which holds a description of your whole site. Sure it's no API, but it gets pretty close to what you mention. Despite that I think struts(2) is in a rather good position. The biggest deficit is IMO in documentation, and a comprehensible, easy-to- use taglib with simple AJAX functions which encapsulates all the fuzzy client side stuff or users who don't want to learn JavaScript, but at the same are easily to extend by Pros. Both things are known to the readers of this list and are (more or less) worked on. Cheers, -Ralf [1] http://groups.google.com/group/google-sitemaps/topics?start=20&sa=N Anyway, despite that, I took this approach recently with a client- heavy (single page) application myself, with the exception of autogeneration of the HTML. Basically: - mandated that the client include a custom header (X-RequestedBy) and signature in the request - if headers present, the S2 rest plugin handled the request and returned the resource in the requested content type. I just had to build the view myself for html. - if the header's not present and it was a GET, the REST plugin returned the HTML view and sitemesh decorated it as a full HTML PAGE. - if a resource was requested directly and the user had javascript, they were redirected to the rich client with the best-guess initial state based on the URI - all flow control is managed on the client. That meant that one action could service requests for the resource for rich clients and support search engines requests for the same content. Search engines could browse the site through the same content spread over many little well-formed pages. Users accessing the site via the search engine's sub-URI would see the rich client with appropriate initial state derived from the URI On the client-side sensible URIs could still be used in links and listeners adjusted the content type when appropriate. Users without JS could get by but were a low priority. Users with screen readers are still a challenge but not due to struts. This approach wasn't as simple as it should be though but confirms that Don's idea is feasible. The biggest problem was in fact with IE6 memory leaks and the poor performance of javascript in most browsers. A flex client could have used the same services without a problem. If automation of a bland html view with a sitemap were provided for users without javascript/flas
Re: S2 as JSR for Action Framework
Don Brown wrote: > This is a nice design, when you can do it. GWT is also a good way to > build these types of apps. Unfortunately, they can easily break much > of what makes the web what it is - the back button, unique, > addressable URI's, accessibility, search engine crawling, etc. > It's always interesting how often you hear the "this breaks the web" sorts of statements. I'm not arguing the factuality of the statement, I just find it interesting. It's also interesting the way you put it here... you don't say anything like "this breaks the web", nor do you make a value judgment on it (well, I suppose the word "unfortunately" implies a value judgment, but it's not explicit). I think we're at an interesting point in time right now... many people are kind of mentally stuck in the sense that they see the ways in which RIAs (can) break things like the back button and they think "well, that's bad". But, maybe we shouldn't be asking if RIAs are the way to go, but we should instead be asking different questions like "is the back button as a navigational metaphor something we really want to be perpetuating anyway"? It's kind of like if someone came up with a hydrogen-based fuel system for cars but for some reason (work with me here!) you could never use a cell phone in the car or it'd explode... I don't think we shouldn't at that point be asking if the fuel system is the right answer or not, we should be asking whether the limitation it imposes is something that should factor into the decision at all in the first place. Wouldn't we be better off if you couldn't use cell phones in cars anyway?!? Note that I'm not making a value judgment here either necessarily, although I suspect my opinion is fairly obvious :) I do think we're in the midst of a paradigm shift to a large extent, and I think there's some fascinating consequences of that shift. Frank -- Frank W. Zammetti Author of "Practical Dojo Projects" abd "Practical DWR 2 Projects" and "Practical JavaScript, DOM Scripting and Ajax Projects" and "Practical Ajax Projects With Java Technology" (For info: apress.com/book/search?searchterm=zammetti&act=search) My "look ma, I have a blog too!" blog: zammetti.com/blog > Don > > >> -- >> Martin Cooper >> >> >> This idea of a JSR would be standardizing the third group, but I >> >>> wonder if maybe the better direction to go is not a new API, but build >>> extensions on JAX-RS [2]. To me, this group's niche is apps that need >>> lightweight presentation engines a layer above servlets, but still >>> very much "web-y". JSR 311 aims to make restful resources easy to >>> build, which isn't far from restful web applications. Especially as >>> more and more applications are starting to rely on client-side AJAX >>> interfaces, the need for a solid RESTful backend only gets stronger. >>> The storage of server-side state of the component frameworks becomes >>> less important, and if you don't want the bulk of Grails, this >>> approach may be attractive. >>> >>> For my day job, we need to build REST interfaces to our web apps, so >>> we are looking to standardize on JAX-RS. Well, we also need a >>> lightweight web framework for our plugin system, and if we are already >>> using something like Jersey [3], it would be nice to be able to write >>> web apps using the same technology. This use case is obviously very >>> specific to our situation, but it is the direction I'll likely be >>> taking in the next few months. >>> >>> Don >>> >>> [1] http://www.source-code.biz/MiniTemplator/ >>> [2] https://jsr311.dev.java.net/ >>> [3] https://jersey.dev.java.net/ >>> >>> On Fri, Aug 22, 2008 at 4:31 PM, Frans Thamura <[EMAIL PROTECTED]> wrote: >>> hi all is it possible that S2 become part of JCP? java server action framework right now only component framework there any idea? -- -- Frans Thamura Meruvian Foundation Mobile: +62 855 7888 699 Linkedin: http://www.linkedin.com/in/fthamura Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... URL: >>> http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco >>> - 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] >>> >>> >>> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > __ Information from ESET Smart Security, version of virus signature > database 3383 (20080824) __ > > The message was checked by ESET Smart
Re: S2 as JSR for Action Framework
Don Brown wrote: On Mon, Aug 25, 2008 at 12:54 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: Another option is a client-side component-based framework like Ext or Flex running directly against web services, RESTful or otherwise. No server-side web framework required. Of course, you could use something server-side like DWR to facilitate working with web services, or Jersey for RESTful services, but that would be a choice rather than a requirement. This is a nice design, when you can do it. GWT is also a good way to build these types of apps. Unfortunately, they can easily break much of what makes the web what it is - the back button, unique, addressable URI's, accessibility, search engine crawling, etc. Therefore, I think some sort of server-side web framework will usually be necessary, however, I don't think it has to go so far as JSF, where they try to push all the state to the server. I was talking with a guy here at work who is looking to start using GWT more about how and where a plain HTML view of the application fits. He wants to do very dynamic, client-side heavy views, but still needs to support search engines and REST clients. What if you use Jersey for your REST API, GWT or straight JQuery for your client-side UI, then have Jersey + something generate HTML views of your REST API, which you could use for search engines and developers wanting to browse and interact with your application. If you can have the HTML representation of your REST API auto-generated, you wouldn't have to maintain two different interfaces, and you could go fully nuts with your client-side heavy app without having to worry about accessibility or search engine issues. Don [rant] Personally I think search engines need to solve this problem. The era of crawling sites needs to close. As a publisher of content I should be able to connect to a Google API and publish my content and URIs to them in a standard machine-friendly format ready for indexing. Alternatively, I could implement a dedicated-service for them to consume instead of emulating pages of content in a non-page-oriented application. Then my application then can be what it needs to be in any form suitable for my users instead of perpetuating the artificial SEO-optimzation industry. [/rant] Anyway, despite that, I took this approach recently with a client-heavy (single page) application myself, with the exception of autogeneration of the HTML. Basically: - mandated that the client include a custom header (X-RequestedBy) and signature in the request - if headers present, the S2 rest plugin handled the request and returned the resource in the requested content type. I just had to build the view myself for html. - if the header's not present and it was a GET, the REST plugin returned the HTML view and sitemesh decorated it as a full HTML PAGE. - if a resource was requested directly and the user had javascript, they were redirected to the rich client with the best-guess initial state based on the URI - all flow control is managed on the client. That meant that one action could service requests for the resource for rich clients and support search engines requests for the same content. Search engines could browse the site through the same content spread over many little well-formed pages. Users accessing the site via the search engine's sub-URI would see the rich client with appropriate initial state derived from the URI On the client-side sensible URIs could still be used in links and listeners adjusted the content type when appropriate. Users without JS could get by but were a low priority. Users with screen readers are still a challenge but not due to struts. This approach wasn't as simple as it should be though but confirms that Don's idea is feasible. The biggest problem was in fact with IE6 memory leaks and the poor performance of javascript in most browsers. A flex client could have used the same services without a problem. If automation of a bland html view with a sitemap were provided for users without javascript/flash you'd eliminate the double-up on the views for search engines. I definitely like the direction these discussions are going. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
On Mon, Aug 25, 2008 at 12:54 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: > Another option is a client-side component-based framework like Ext or Flex > running directly against web services, RESTful or otherwise. No server-side > web framework required. Of course, you could use something server-side like > DWR to facilitate working with web services, or Jersey for RESTful services, > but that would be a choice rather than a requirement. This is a nice design, when you can do it. GWT is also a good way to build these types of apps. Unfortunately, they can easily break much of what makes the web what it is - the back button, unique, addressable URI's, accessibility, search engine crawling, etc. Therefore, I think some sort of server-side web framework will usually be necessary, however, I don't think it has to go so far as JSF, where they try to push all the state to the server. I was talking with a guy here at work who is looking to start using GWT more about how and where a plain HTML view of the application fits. He wants to do very dynamic, client-side heavy views, but still needs to support search engines and REST clients. What if you use Jersey for your REST API, GWT or straight JQuery for your client-side UI, then have Jersey + something generate HTML views of your REST API, which you could use for search engines and developers wanting to browse and interact with your application. If you can have the HTML representation of your REST API auto-generated, you wouldn't have to maintain two different interfaces, and you could go fully nuts with your client-side heavy app without having to worry about accessibility or search engine issues. Don > > -- > Martin Cooper > > > This idea of a JSR would be standardizing the third group, but I >> wonder if maybe the better direction to go is not a new API, but build >> extensions on JAX-RS [2]. To me, this group's niche is apps that need >> lightweight presentation engines a layer above servlets, but still >> very much "web-y". JSR 311 aims to make restful resources easy to >> build, which isn't far from restful web applications. Especially as >> more and more applications are starting to rely on client-side AJAX >> interfaces, the need for a solid RESTful backend only gets stronger. >> The storage of server-side state of the component frameworks becomes >> less important, and if you don't want the bulk of Grails, this >> approach may be attractive. >> >> For my day job, we need to build REST interfaces to our web apps, so >> we are looking to standardize on JAX-RS. Well, we also need a >> lightweight web framework for our plugin system, and if we are already >> using something like Jersey [3], it would be nice to be able to write >> web apps using the same technology. This use case is obviously very >> specific to our situation, but it is the direction I'll likely be >> taking in the next few months. >> >> Don >> >> [1] http://www.source-code.biz/MiniTemplator/ >> [2] https://jsr311.dev.java.net/ >> [3] https://jersey.dev.java.net/ >> >> On Fri, Aug 22, 2008 at 4:31 PM, Frans Thamura <[EMAIL PROTECTED]> wrote: >> > hi all >> > >> > is it possible that S2 become part of JCP? >> > >> > java server action framework >> > >> > right now only component framework there >> > >> > any idea? >> > >> > >> > >> > -- >> > -- >> > Frans Thamura >> > Meruvian Foundation >> > >> > Mobile: +62 855 7888 699 >> > Linkedin: http://www.linkedin.com/in/fthamura >> > >> > Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... >> > URL: >> http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco >> > >> > - >> > 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] >> >> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
> Another option is a client-side component-based framework like Ext or Flex > running directly against web services, RESTful or otherwise. No server-side > web framework required. Of course, you could use something server-side like > DWR to facilitate working with web services, or Jersey for RESTful services, > but that would be a choice rather than a requirement. i think the future in this area of S2 S2 as a SOA server and also a AJAX server, both produce same JSON output as REstful implementaiton i see the merger between AJAX and SOA, is this caled SaaS? F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
On Fri, Aug 22, 2008 at 8:36 PM, Don Brown <[EMAIL PROTECTED]> wrote: > Personally, I don't think Struts 2 has a strong enough API, ok, I > _know_ Struts 2 doesn't have a strong enough API to be turned into a > JSR, currently anyway. Bob did some work trying to define such an > API, and is probably 80% of the way there, but I wonder if the > technology has moved on a bit since then... > > For fun in a side project, I'm going back to pure Servlets and a > simple template language [1] to better understand what a web framework > really needs to provide. As I see the options now you have: > * Rails/Merb/Grails - rapid development, scripting language base, > solid best of breed stack (for Grails anyway) under the covers. On > the other hand, using any of these to write a hello world war is > something like 25 megabytes and a ton of dependencies. That is fine > for shops that need to get something up quickly and are starting from > scratch, but not for others. > * JSF/Wicket/Tapestry - component development for swing/drag-and-drop > folks, ability to wrap up complex bits into new components, usually > nice tool support. On the other hand, their apps tend to not be > RESTful and take you quite a ways from HTTP. Also, they usually > involve a lot of server-side state management which can impact > scalability and they sometimes rely on a Javascript to really work. > Finally, each tends to really favor their one template language by > design, limiting options down the road. > * Struts/Stripes/Spring MVC - lightweight MVC frameworks with minimal > dependencies, with a specific focus on the presentation tier. Easy > access to HTTP features, not much to learn, can fit easily into most > application stacks, and tend to be very RESTful. These frameworks > tend to be fast, impose little requirements on the session, and work > with most template engines. Another option is a client-side component-based framework like Ext or Flex running directly against web services, RESTful or otherwise. No server-side web framework required. Of course, you could use something server-side like DWR to facilitate working with web services, or Jersey for RESTful services, but that would be a choice rather than a requirement. -- Martin Cooper This idea of a JSR would be standardizing the third group, but I > wonder if maybe the better direction to go is not a new API, but build > extensions on JAX-RS [2]. To me, this group's niche is apps that need > lightweight presentation engines a layer above servlets, but still > very much "web-y". JSR 311 aims to make restful resources easy to > build, which isn't far from restful web applications. Especially as > more and more applications are starting to rely on client-side AJAX > interfaces, the need for a solid RESTful backend only gets stronger. > The storage of server-side state of the component frameworks becomes > less important, and if you don't want the bulk of Grails, this > approach may be attractive. > > For my day job, we need to build REST interfaces to our web apps, so > we are looking to standardize on JAX-RS. Well, we also need a > lightweight web framework for our plugin system, and if we are already > using something like Jersey [3], it would be nice to be able to write > web apps using the same technology. This use case is obviously very > specific to our situation, but it is the direction I'll likely be > taking in the next few months. > > Don > > [1] http://www.source-code.biz/MiniTemplator/ > [2] https://jsr311.dev.java.net/ > [3] https://jersey.dev.java.net/ > > On Fri, Aug 22, 2008 at 4:31 PM, Frans Thamura <[EMAIL PROTECTED]> wrote: > > hi all > > > > is it possible that S2 become part of JCP? > > > > java server action framework > > > > right now only component framework there > > > > any idea? > > > > > > > > -- > > -- > > Frans Thamura > > Meruvian Foundation > > > > Mobile: +62 855 7888 699 > > Linkedin: http://www.linkedin.com/in/fthamura > > > > Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... > > URL: > http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco > > > > - > > 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: S2 as JSR for Action Framework
On Sat, Aug 23, 2008 at 9:04 PM, Ian Roughley <[EMAIL PROTECTED]> wrote: > I've also been thinking along these lines, starting about a year back when > there was discussions around the convention plug-in. Although it was > motivated more on a clean annotation implementation - as there seemed to be > a good synergy between the JSR-311 annotations and what s2 could leverage > (as opposed to defining new annotations). if S2 join any JSR or synergy with JSR 311 or anything, or use any JSR that will be cool. but if the controller can become another JSR, that will be amazing. NB: i still dont get, how can JSF become JSR, when in that time Struts is the market leader, and why dont use S1 as the JSR baseline... a lot of complain come becuse people want JSR implementation in their system, and they must migrate S1 to another framework in amazinngly painfull. F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
I've also been thinking along these lines, starting about a year back when there was discussions around the convention plug-in. Although it was motivated more on a clean annotation implementation - as there seemed to be a good synergy between the JSR-311 annotations and what s2 could leverage (as opposed to defining new annotations). /Ian Don Brown wrote: Personally, I don't think Struts 2 has a strong enough API, ok, I _know_ Struts 2 doesn't have a strong enough API to be turned into a JSR, currently anyway. Bob did some work trying to define such an API, and is probably 80% of the way there, but I wonder if the technology has moved on a bit since then... For fun in a side project, I'm going back to pure Servlets and a simple template language [1] to better understand what a web framework really needs to provide. As I see the options now you have: * Rails/Merb/Grails - rapid development, scripting language base, solid best of breed stack (for Grails anyway) under the covers. On the other hand, using any of these to write a hello world war is something like 25 megabytes and a ton of dependencies. That is fine for shops that need to get something up quickly and are starting from scratch, but not for others. * JSF/Wicket/Tapestry - component development for swing/drag-and-drop folks, ability to wrap up complex bits into new components, usually nice tool support. On the other hand, their apps tend to not be RESTful and take you quite a ways from HTTP. Also, they usually involve a lot of server-side state management which can impact scalability and they sometimes rely on a Javascript to really work. Finally, each tends to really favor their one template language by design, limiting options down the road. * Struts/Stripes/Spring MVC - lightweight MVC frameworks with minimal dependencies, with a specific focus on the presentation tier. Easy access to HTTP features, not much to learn, can fit easily into most application stacks, and tend to be very RESTful. These frameworks tend to be fast, impose little requirements on the session, and work with most template engines. This idea of a JSR would be standardizing the third group, but I wonder if maybe the better direction to go is not a new API, but build extensions on JAX-RS [2]. To me, this group's niche is apps that need lightweight presentation engines a layer above servlets, but still very much "web-y". JSR 311 aims to make restful resources easy to build, which isn't far from restful web applications. Especially as more and more applications are starting to rely on client-side AJAX interfaces, the need for a solid RESTful backend only gets stronger. The storage of server-side state of the component frameworks becomes less important, and if you don't want the bulk of Grails, this approach may be attractive. For my day job, we need to build REST interfaces to our web apps, so we are looking to standardize on JAX-RS. Well, we also need a lightweight web framework for our plugin system, and if we are already using something like Jersey [3], it would be nice to be able to write web apps using the same technology. This use case is obviously very specific to our situation, but it is the direction I'll likely be taking in the next few months. Don [1] http://www.source-code.biz/MiniTemplator/ [2] https://jsr311.dev.java.net/ [3] https://jersey.dev.java.net/ On Fri, Aug 22, 2008 at 4:31 PM, Frans Thamura <[EMAIL PROTECTED]> wrote: hi all is it possible that S2 become part of JCP? java server action framework right now only component framework there any idea? -- -- Frans Thamura Meruvian Foundation Mobile: +62 855 7888 699 Linkedin: http://www.linkedin.com/in/fthamura Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... URL: http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco - 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: S2 as JSR for Action Framework
Personally, I don't think Struts 2 has a strong enough API, ok, I _know_ Struts 2 doesn't have a strong enough API to be turned into a JSR, currently anyway. Bob did some work trying to define such an API, and is probably 80% of the way there, but I wonder if the technology has moved on a bit since then... For fun in a side project, I'm going back to pure Servlets and a simple template language [1] to better understand what a web framework really needs to provide. As I see the options now you have: * Rails/Merb/Grails - rapid development, scripting language base, solid best of breed stack (for Grails anyway) under the covers. On the other hand, using any of these to write a hello world war is something like 25 megabytes and a ton of dependencies. That is fine for shops that need to get something up quickly and are starting from scratch, but not for others. * JSF/Wicket/Tapestry - component development for swing/drag-and-drop folks, ability to wrap up complex bits into new components, usually nice tool support. On the other hand, their apps tend to not be RESTful and take you quite a ways from HTTP. Also, they usually involve a lot of server-side state management which can impact scalability and they sometimes rely on a Javascript to really work. Finally, each tends to really favor their one template language by design, limiting options down the road. * Struts/Stripes/Spring MVC - lightweight MVC frameworks with minimal dependencies, with a specific focus on the presentation tier. Easy access to HTTP features, not much to learn, can fit easily into most application stacks, and tend to be very RESTful. These frameworks tend to be fast, impose little requirements on the session, and work with most template engines. This idea of a JSR would be standardizing the third group, but I wonder if maybe the better direction to go is not a new API, but build extensions on JAX-RS [2]. To me, this group's niche is apps that need lightweight presentation engines a layer above servlets, but still very much "web-y". JSR 311 aims to make restful resources easy to build, which isn't far from restful web applications. Especially as more and more applications are starting to rely on client-side AJAX interfaces, the need for a solid RESTful backend only gets stronger. The storage of server-side state of the component frameworks becomes less important, and if you don't want the bulk of Grails, this approach may be attractive. For my day job, we need to build REST interfaces to our web apps, so we are looking to standardize on JAX-RS. Well, we also need a lightweight web framework for our plugin system, and if we are already using something like Jersey [3], it would be nice to be able to write web apps using the same technology. This use case is obviously very specific to our situation, but it is the direction I'll likely be taking in the next few months. Don [1] http://www.source-code.biz/MiniTemplator/ [2] https://jsr311.dev.java.net/ [3] https://jersey.dev.java.net/ On Fri, Aug 22, 2008 at 4:31 PM, Frans Thamura <[EMAIL PROTECTED]> wrote: > hi all > > is it possible that S2 become part of JCP? > > java server action framework > > right now only component framework there > > any idea? > > > > -- > -- > Frans Thamura > Meruvian Foundation > > Mobile: +62 855 7888 699 > Linkedin: http://www.linkedin.com/in/fthamura > > Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... > URL: > http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco > > - > 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: S2 as JSR for Action Framework
> The other point to remember is that this is an all-volunteer open source > project. To my knowledge, none of the Struts committers is paid to work on > the development of Struts. Who, exactly, do you imagine would be spending > their volunteer time sitting on a JCP committee trying to push S2 through > the standards process? It's *highly* unlikely to be the S2 developers, so > what you get at the end of the process is highly unlikely to be much like > S2. You are right on here. If anyone has some free time to spare, that time would better go into improving the documentation,fixing bugs, or helping on the mailing lists. Let companies play their politics and games, we, we just write code. musachy -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
I am -1 on having Struts 2 be a JSR. Anything that gets pulled into JEE gets pulled into molasses and I wouldn't want Sun to stick their hands into this framework. With that said, I wouldn't mind a JSR that creates an JEE Action Framework that Struts 2 is an implementation of. Remember the great success Hibernate had with leading the JPA spec? How about Joda Time leading JSR-310 Date and Time API? Replicate the procedures that lead to success. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
> Struts was, and probably still is, by far the most popular and widely > deployed web framework on the planet, all without the help of the JCP. There > are numerous companies that provide commercial support for Struts solely > because of that. Some of the companies you list above have invested a lot in > Struts to provide tooling for it because of the demand for that tooling, > despite it having no "official" status as a standard. make it the one again :) > I don't understand your point. Jetspeed 1 existed before JSR 168 and was a > proprietary, non-standard portal technology for a long time, because there > was no standard back then. Every portal vendor had their own technology. > When JSR 168 was formalised, the Pluto code base was donated to the Jetspeed > project by IBM as the reference implementation for that. Jetspeed 2 was then > designed around JSR 168 and incorporated the Pluto RI. in that time, if we develop "portlet", there is portal software, ibm portal .. > > Where is the analogy with Struts? Are you suggesting that, if by some chance > the JCP went off and defined a standard action framework that wasn't Struts, > and Struts didn't implement that specification, the Struts framework would > die? That's a tremendous amount of wild speculation, and not something I > would be willing to base any project decisions on at this point in time! we can call JavaServer ActionFramework and Struts as the implementation of it. so Struts can get JSR 123 and we can add several controller implemenation, if SpringMVC guy in abroad. but of course Struts ActionSupport is the simplest one i > We're not a movement, we're an open source project. ;-) i am not just a struts2 supporter, since webwork 2.0 in our country, and i see that the component framework is more stronger than action, and people keep compare Struts with JSF, i think this is not apple to apple F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
On Fri, Aug 22, 2008 at 5:45 PM, Frans Thamura <[EMAIL PROTECTED]> wrote: > > > > Anything's possible. ;-) But why would you do that? Sure, it might result > in > > S2 eventually becoming part of Java EE, but Struts has been pretty > > successful over the last 8 years or so without that, as have other > > frameworks like Spring and Hibernate. By turning S2 into a JSR, you then > end > > up with "design by committee", and lose much of the ability to innovate > > since you're constrained by what's in the JSR. > > > S2 based on WW, and we know also JCP also have several big company > that spending in this brand, IBM, Oracle, Sun, RedHat, and the user > believe that the standard will make the investment more trusted, of > course Apache is the most trusted one also in non dejure world. using > Apache brand, the movement will still move. Struts was, and probably still is, by far the most popular and widely deployed web framework on the planet, all without the help of the JCP. There are numerous companies that provide commercial support for Struts solely because of that. Some of the companies you list above have invested a lot in Struts to provide tooling for it because of the demand for that tooling, despite it having no "official" status as a standard. > i active in Jetspeed long before Jetspeed become JSR 168, and can u > imagine what happen if Jetspeed develop a non standard tech, what do > you think of pluto? I don't understand your point. Jetspeed 1 existed before JSR 168 and was a proprietary, non-standard portal technology for a long time, because there was no standard back then. Every portal vendor had their own technology. When JSR 168 was formalised, the Pluto code base was donated to the Jetspeed project by IBM as the reference implementation for that. Jetspeed 2 was then designed around JSR 168 and incorporated the Pluto RI. Where is the analogy with Struts? Are you suggesting that, if by some chance the JCP went off and defined a standard action framework that wasn't Struts, and Struts didn't implement that specification, the Struts framework would die? That's a tremendous amount of wild speculation, and not something I would be willing to base any project decisions on at this point in time! > i think the dispatcher mechanism and http and rest tech is the strong > point in struts2 and we cannot see JSF model will got this, because > different approach in development. > > my idea is to make new java people and big company that dont want to > put their risk can use Struts2. They can do that today. Struts has a long history - longer than any other Java web framework - of providing a strong framework with a strong community to back it up. Neither of those things are going away. The other point to remember is that this is an all-volunteer open source project. To my knowledge, none of the Struts committers is paid to work on the development of Struts. Who, exactly, do you imagine would be spending their volunteer time sitting on a JCP committee trying to push S2 through the standards process? It's *highly* unlikely to be the S2 developers, so what you get at the end of the process is highly unlikely to be much like S2. this will make the movement more stronger. We're not a movement, we're an open source project. ;-) -- Martin Cooper > > > > F > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: S2 as JSR for Action Framework
> > Anything's possible. ;-) But why would you do that? Sure, it might result in > S2 eventually becoming part of Java EE, but Struts has been pretty > successful over the last 8 years or so without that, as have other > frameworks like Spring and Hibernate. By turning S2 into a JSR, you then end > up with "design by committee", and lose much of the ability to innovate > since you're constrained by what's in the JSR. S2 based on WW, and we know also JCP also have several big company that spending in this brand, IBM, Oracle, Sun, RedHat, and the user believe that the standard will make the investment more trusted, of course Apache is the most trusted one also in non dejure world. using Apache brand, the movement will still move. i active in Jetspeed long before Jetspeed become JSR 168, and can u imagine what happen if Jetspeed develop a non standard tech, what do you think of pluto? i think the dispatcher mechanism and http and rest tech is the strong point in struts2 and we cannot see JSF model will got this, because different approach in development. my idea is to make new java people and big company that dont want to put their risk can use Struts2. this will make the movement more stronger. F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
my experience here, i am the company that selling struts2 in this country and we see that JSF have several complain in several case esp the high performance and we see that people try to say JavaEE as the standard, and we must strict with all JCP related, like JSF, and if we can make S2 as the action standard, we can have another way of devleopment in 'JCP' and also use JCP brand as standard body.. and hopefully can work together with SpringMVC.. who know. the power of Java is standard, isnt it? so i think the slow movement in struts because struts is not part of the standard. i believe struts2 is the most easies and best Action framework in the earth and also the standard will make the big vendor also supporting s2, make plugins etc etc.. i think right now there is only IDEA 8 that will support S2, and the rest is just JSF F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
On Fri, Aug 22, 2008 at 12:47 PM, Gabriel Belingueres <[EMAIL PROTECTED]> wrote: > The scenario where S2 would become a JCP approved JSR is pretty much scary > IMO: > > 1) It means it exists a Reference Implementation of S2, or that S2 is > build upon a RI of something else. > 2) Any vendor can come up with their own flavors and extensions of the > JSR, which brings more FUD than solutions. > > Instead, I'd like to see S2 building functionality upon itself more like: > > 1) the "flow" concept (like Spring WF) > 2) improving validation framework (validating against JSR 303 compliant > POJOs)i > > or other things that are not framework specific but useful, like > having a repository of themes for changing the L&F of the apps. Think > having to develop a new app, your customer pick a design from > www.oswd.org and you have to create a new theme for that particular > design. If you could just find that theme already built THAT would be > a time saver. I don't disagree, but this is an interesting read along a similar topic: http://adactio.com/journal/1498 Matt > > 2008/8/22, Wendy Smoak <[EMAIL PROTECTED]>: >> On Thu, Aug 21, 2008 at 11:31 PM, Frans Thamura <[EMAIL PROTECTED]> wrote: >> >> > is it possible that S2 become part of JCP? >> > java server action framework >> > right now only component framework there >> > any idea? >> >> While I cringe every time I hear someone say that they chose JSF >> because "It's the standard" there's no way I would want to see Struts >> 2 attempt the JCP. It wouldn't be Struts 2 by the time you came out >> the other end, and, well... what Martin said. ;) >> >> -- >> Wendy >> >> - >> 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] > > -- http://raibledesigns.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
The scenario where S2 would become a JCP approved JSR is pretty much scary IMO: 1) It means it exists a Reference Implementation of S2, or that S2 is build upon a RI of something else. 2) Any vendor can come up with their own flavors and extensions of the JSR, which brings more FUD than solutions. Instead, I'd like to see S2 building functionality upon itself more like: 1) the "flow" concept (like Spring WF) 2) improving validation framework (validating against JSR 303 compliant POJOs)i or other things that are not framework specific but useful, like having a repository of themes for changing the L&F of the apps. Think having to develop a new app, your customer pick a design from www.oswd.org and you have to create a new theme for that particular design. If you could just find that theme already built THAT would be a time saver. 2008/8/22, Wendy Smoak <[EMAIL PROTECTED]>: > On Thu, Aug 21, 2008 at 11:31 PM, Frans Thamura <[EMAIL PROTECTED]> wrote: > > > is it possible that S2 become part of JCP? > > java server action framework > > right now only component framework there > > any idea? > > While I cringe every time I hear someone say that they chose JSF > because "It's the standard" there's no way I would want to see Struts > 2 attempt the JCP. It wouldn't be Struts 2 by the time you came out > the other end, and, well... what Martin said. ;) > > -- > Wendy > > - > 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: S2 as JSR for Action Framework
On Thu, Aug 21, 2008 at 11:31 PM, Frans Thamura <[EMAIL PROTECTED]> wrote: > is it possible that S2 become part of JCP? > java server action framework > right now only component framework there > any idea? While I cringe every time I hear someone say that they chose JSF because "It's the standard" there's no way I would want to see Struts 2 attempt the JCP. It wouldn't be Struts 2 by the time you came out the other end, and, well... what Martin said. ;) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
On Thu, Aug 21, 2008 at 11:31 PM, Frans Thamura <[EMAIL PROTECTED]> wrote: > hi all > > is it possible that S2 become part of JCP? Anything's possible. ;-) But why would you do that? Sure, it might result in S2 eventually becoming part of Java EE, but Struts has been pretty successful over the last 8 years or so without that, as have other frameworks like Spring and Hibernate. By turning S2 into a JSR, you then end up with "design by committee", and lose much of the ability to innovate since you're constrained by what's in the JSR. -- Martin Cooper > > java server action framework > > right now only component framework there > > any idea? > > > > -- > -- > Frans Thamura > Meruvian Foundation > > Mobile: +62 855 7888 699 > Linkedin: http://www.linkedin.com/in/fthamura > > Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... > URL: > http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: S2 as JSR for Action Framework
Ian Roughley wrote: > Maybe no-one wants to admit it publicly :-) Well, if that were true, it'd be a bigger problem than simply slow adoption rates :) -- Frank W. Zammetti Author of "Practical Dojo Projects" abd "Practical DWR 2 Projects" and "Practical JavaScript, DOM Scripting and Ajax Projects" and "Practical Ajax Projects With Java Technology" (For info: apress.com/book/search?searchterm=zammetti&act=search) My "look ma, I have a blog too!" blog: zammetti.com/blog > Not that it's a particularly good metric, but I always thought the > adoption rates were very slow. However, I'm always surprised how many > companies are using s2 when I speak to people at conferences. Maybe > no-one wants to admit it publicly :-) > /Ian > > James Mitchell wrote: >> That's a hard question to answer. It's probably like politics. >> You'll get completely different answers depending on who you ask. >> >> On Fri, Aug 22, 2008 at 11:11 AM, Musachy Barroso <[EMAIL PROTECTED]> >> wrote: >> >>> That's a good point, and I do have a question myself, how are we doing >>> adoption-wise? Judging from the users mailing list traffic, I would >>> say well. In any case, just better of talking about this on the user >>> list rather than here. >>> >>> musachy >>> >>> On Fri, Aug 22, 2008 at 10:52 AM, James Mitchell >>> <[EMAIL PROTECTED]> wrote: >>> Let the marketplace decide. Just my $0.02 On Fri, Aug 22, 2008 at 2:31 AM, Frans Thamura <[EMAIL PROTECTED]> wrote: > hi all > > is it possible that S2 become part of JCP? > > java server action framework > > right now only component framework there > > any idea? > > > > -- > -- > Frans Thamura > Meruvian Foundation > > Mobile: +62 855 7888 699 > Linkedin: http://www.linkedin.com/in/fthamura > > Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... > URL: > http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> -- >>> "Hey you! Would you help me to carry the stone?" Pink Floyd >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> >> >> > > > > __ Information from ESET Smart Security, version of virus > signature database 3380 (20080822) __ > > The message was checked by ESET Smart Security. > > http://www.eset.com > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
Not that it's a particularly good metric, but I always thought the adoption rates were very slow. However, I'm always surprised how many companies are using s2 when I speak to people at conferences. Maybe no-one wants to admit it publicly :-) /Ian James Mitchell wrote: That's a hard question to answer. It's probably like politics. You'll get completely different answers depending on who you ask. On Fri, Aug 22, 2008 at 11:11 AM, Musachy Barroso <[EMAIL PROTECTED]> wrote: That's a good point, and I do have a question myself, how are we doing adoption-wise? Judging from the users mailing list traffic, I would say well. In any case, just better of talking about this on the user list rather than here. musachy On Fri, Aug 22, 2008 at 10:52 AM, James Mitchell <[EMAIL PROTECTED]> wrote: Let the marketplace decide. Just my $0.02 On Fri, Aug 22, 2008 at 2:31 AM, Frans Thamura <[EMAIL PROTECTED]> wrote: hi all is it possible that S2 become part of JCP? java server action framework right now only component framework there any idea? -- -- Frans Thamura Meruvian Foundation Mobile: +62 855 7888 699 Linkedin: http://www.linkedin.com/in/fthamura Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... URL: http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
That's a hard question to answer. It's probably like politics. You'll get completely different answers depending on who you ask. On Fri, Aug 22, 2008 at 11:11 AM, Musachy Barroso <[EMAIL PROTECTED]> wrote: > That's a good point, and I do have a question myself, how are we doing > adoption-wise? Judging from the users mailing list traffic, I would > say well. In any case, just better of talking about this on the user > list rather than here. > > musachy > > On Fri, Aug 22, 2008 at 10:52 AM, James Mitchell <[EMAIL PROTECTED]> wrote: >> Let the marketplace decide. >> >> Just my $0.02 >> >> On Fri, Aug 22, 2008 at 2:31 AM, Frans Thamura <[EMAIL PROTECTED]> wrote: >>> hi all >>> >>> is it possible that S2 become part of JCP? >>> >>> java server action framework >>> >>> right now only component framework there >>> >>> any idea? >>> >>> >>> >>> -- >>> -- >>> Frans Thamura >>> Meruvian Foundation >>> >>> Mobile: +62 855 7888 699 >>> Linkedin: http://www.linkedin.com/in/fthamura >>> >>> Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... >>> URL: >>> http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> >> -- >> James Mitchell >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > -- > "Hey you! Would you help me to carry the stone?" Pink Floyd > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
That's a good point, and I do have a question myself, how are we doing adoption-wise? Judging from the users mailing list traffic, I would say well. In any case, just better of talking about this on the user list rather than here. musachy On Fri, Aug 22, 2008 at 10:52 AM, James Mitchell <[EMAIL PROTECTED]> wrote: > Let the marketplace decide. > > Just my $0.02 > > On Fri, Aug 22, 2008 at 2:31 AM, Frans Thamura <[EMAIL PROTECTED]> wrote: >> hi all >> >> is it possible that S2 become part of JCP? >> >> java server action framework >> >> right now only component framework there >> >> any idea? >> >> >> >> -- >> -- >> Frans Thamura >> Meruvian Foundation >> >> Mobile: +62 855 7888 699 >> Linkedin: http://www.linkedin.com/in/fthamura >> >> Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... >> URL: >> http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > -- > James Mitchell > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
Let the marketplace decide. Just my $0.02 On Fri, Aug 22, 2008 at 2:31 AM, Frans Thamura <[EMAIL PROTECTED]> wrote: > hi all > > is it possible that S2 become part of JCP? > > java server action framework > > right now only component framework there > > any idea? > > > > -- > -- > Frans Thamura > Meruvian Foundation > > Mobile: +62 855 7888 699 > Linkedin: http://www.linkedin.com/in/fthamura > > Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... > URL: > http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
