I've been putting the documentation for the JSON plugin on the plugin page, in the plugin registry. I'm not quite sure if this is ok(given that the plugins are not part of struts) but nobody has complained so far :), so I guess it is ok to use the wiki.
musachy On 5/30/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
Sounds good. For now I'm planning on continuing the documentation and doing a release of the plugin as it is. I have a few projects coming up in the next few weeks that I'll be using the plugin. For the documentation, should I go ahead and put it up on the Struts2 wiki? I have my contributor agreement, I just need to fax it in. -bp Don Brown wrote: > Sounds good. I should have some time in a few weeks to take a look at > this. I really like what you've done and hope to get as much as > reasonable > into core. > > Don > > On 5/30/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: >> >> >> I could go either way. I would be happy to support both methods for >> this, either in core or as a separate plugin via Google-Code. >> >> Right now, I've called it smarturls-s2 and it is up in a Google-Code >> SubVersion repository. The tests are working so they can give you some >> sense of how it all works. Feel free to take a look at the code and let >> me know if you want to move it into core or leave it where it is at. If >> it stays over at Google, I'll add to the project anyone from the main >> Struts2 contributor list that wants access. >> >> One other thing is that for the component support I built in, I used >> JAXB2 from JDK 1.6 for parsing and converting the component.xml files >> into JavaBeans. If we move it back into core we'll need to change that >> over to SAX or some other method of loading in the XML. >> >> All that said, I'm also leaning towards moving it back into core and >> fixing up some of the configuration tricks that it currently requires so >> that it is part of the Struts2 initialization process rather than a >> custom ConfigurationProvider that requires web.xml to have init >> parameters for the FilterDispatcher in order to setup a custom >> configuration provider. >> >> -bp >> >> >> Don Brown wrote: >> > This looks great Brian! Is the code anywhere we could take a look? >> > Do you >> > think it would be better to have this as a plugin or part of the >> > core? I'm >> > leaning towards putting in 2.1.x core, but would like to hear your >> > thoughts. >> > >> > Don >> > >> > On 5/3/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: >> >> >> >> I've finished the first pass at a plugin that collapses the >> zero-config >> >> and code-behind as well as adds support for components that have >> actions >> >> in other JAR files. Here are the highlights: >> >> >> >> - Uses action packages to locate actions >> >> >> >> - Pre-loads all the results it can find via the ServletContext and >> >> Result(s) annotations. Before the unknown handler handled all the >> >> results for zero-config that weren't in the annotations. I changed it >> so >> >> that my configuration provider pre-loads results it can find using >> >> servletContext.getResourcePaths(String). I also added support for >> >> relative path handling for certain result types so that the Result >> >> annotation doesn't have to point to a full path. When it finds a >> JSP or >> >> other file in the web application that looks like a result it will >> >> create a result for it. In addition, rather than only handling >> >> <actionName>-<resultCode>.ext format, it will also creat results for >> >> <actionName>.ext using the resultCodes input, error and success. This >> >> will be the most common handling and this can easily be modified >> using >> >> the annotations. >> >> >> >> - Added support for ActionName(s) annotations that can allow a >> class to >> >> have a different action name and/or multiple actions. It also >> supports >> >> invoking different methods for different actions. >> >> >> >> - Added a configurable interface for converting from the class >> name to >> >> an action name. The default is an SEO friendly mechanism that >> converts >> >> FooBarAction to foo_bar. This interface can be implemented and >> injected >> >> into the configuration process to change action names by default. >> >> Otherwise every action class will need ActionName(s) annotation(s). >> >> >> >> - Added support for moving the base result location. This is the path >> >> where the results are looked for. An action can have a different base >> >> result location than other actions using the BaseResultLocation >> >> annotation. Furthermore, the entire app can control this in the same >> >> manner as the code-behind plugin did. >> >> >> >> - Namespaces and parent packages are handled as they were before. >> >> >> >> - Add component handling via an XML file anywhere in the classpath >> >> called component.xml. This file defines the action packages for a >> >> component and can also move the base result location for the >> component >> >> as well as control the prefix of the namespace for each action >> package. >> >> The configuration looks like this: >> >> >> >> <?xml version="1.0"?> >> >> <component> >> >> <action_package>com.example.component.test</action_package> >> >> <action_package >> >> >> namespace_prefix="/test2">com.example.component.test2</action_package> >> >> <base_result_location>/WEB-INF/component</base_result_location> >> >> <parent_package>foo-bar</parent_package> >> >> </component> >> >> >> >> Actions and results are resolved the same for components as for the >> >> application except with the base result location, parent package and >> >> namespace_prefix tweaks. >> >> >> >> - Everything is interfaced out so it can be extended, refactored or >> >> replaced pretty easily. The entire configuration process is >> handled via >> >> interfaces and injection, so nothing is hard-coded. >> >> >> >> >> >> That's what I have thus far. It is working fine and the component >> >> framework is working well. Everything thus far is pretty well unit >> >> tested as well. Here's what I have left to complete: >> >> >> >> - Add support for component unknown actions and results. This is >> >> required because components can move the base result location, which >> >> means that I need to figure out a way to infer that an action is in a >> >> namespace of a component probably by walking over all the actions in >> all >> >> packages to ensure that the component has an action in that same >> >> namespace. >> >> >> >> If folks have comments or thoughts let me know. >> >> >> >> -bp >> >> >> >> --------------------------------------------------------------------- >> >> 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]
-- "Hey you! Would you help me to carry the stone?" Pink Floyd
