On Friday, January 17, 2014 5:07 PM, David Taylor <davidseantay...@gmail.com> wrote:
> improvements in configurability/extensibility of the reverse proxy >servlet module by using spring framework and spring bean assembling >configuration as well. It's a perfect time to gather contirubtions. Let us >know if you want to help. :-) > >Definitely. One of the tasks in the Roadmap is to look into upgrading >Spring. In projects I've worked on recently, I've been using annotations or >Spring configurations in Java, not the 'old' XML configurations. There is >the new Spring 4.0 to consider. There could be benefit to APA and Jetspeed >sharing the same Spring core Sounds good. I'll write a wiki page soon (probably by Friday) to share and discuss what/how to do for apa-webcontent-2.0 with community. Cheers, Woonsan > > >On Thu, Jan 16, 2014 at 4:19 PM, Woonsan Ko <woon_...@yahoo.com> wrote: > >> Hi David, >> >> Thanks for the quick response! >> >> >> On Thursday, January 16, 2014 9:58 PM, David S Taylor < >> da...@bluesunrise.com> wrote: >> >> > Do you have any objections or different ideas? >> > >> >No objections at all. Makes sense to separate the webapp vs portlet app >> >usage. Hopefully we can get these new improvements included in the next >> >Jetspeed release. >> >> Cool! Thanks! >> If you mean the target release date, April 2014, then I think it's >> feasible. >> >> > >> >> new, more intuitive transformation rules abstracting something like >> >htmlcleaner's TagTransformation [1]2. reverse-proxy >> > >> >So we are going to be basically dumping the existing transformation rules >> >and replacing it with HtmlCleaner? I don't have a problem with that, >> >progress :) >> >> Yeah, probably. :-) >> The XML based rule configuration was quite okay, I believe, but now I feel >> like it lacks of programmagic transformation support based on >> extensible/simple API, and it doesn't seem to cover challenging >> transformation needs. I'd like to rethink it over to find simpler/nicer API >> and its representation (in configuration) as well. HtmlCleaner is just one >> of reference for now. Maybe we can use it or we can steal some of their >> design. It's still open to any other alternatives. Anyway, I expect the >> content-rewriter submodule be a unique/simple/powerful library for many use >> cases. >> >> By the way, as some people asked for this and were even willing to >> contribute, I also want to see improvements in >> configurability/extensibility of the reverse proxy servlet module by using >> spring framework and spring bean assembling configuration as well. It's a >> perfect time to gather contirubtions. Let us know if you want to help. :-) >> >> Thanks again and cheers, >> >> Woonsan >> >> > >> > >> >-- >> >David S Taylor >> >CEO, Bluesunrise >> >707 529-9194 >> >da...@bluesunrise.com >> > >> > >> > >> > >> >On Thu, Jan 16, 2014 at 11:28 AM, Woonsan Ko <woon_...@yahoo.com> wrote: >> > >> >> Hi, >> >> >> >> I'd like to restructure the modules of apa-webcontent and refactor the >> >> html content rewriting modules. >> >> Some people including me use only reverse-proxy servlet in non-portlet >> >> applications in some situations, and the current html content rewriter >> >> feature seems to be tightly coupled with portlet api, so it's hard to >> use >> >> it in that situation. Also, the rewriter rule mechanism doesn't seem to >> >> have been improved for long time and it doesn't look very intuitive any >> >> more. >> >> So, I'm considering new module structure like the following (in the >> >> current structure with webcontent-jar and webcontent-war, you have to >> put >> >> every Java module in webcontent-jar): >> >> >> >> 1. content-rewriter >> >> - content rewriting classes >> >> - no dependency on portlet api or servlet-api >> >> >> >> - new, more intuitive transformation rules abstracting something >> like >> >> htmlcleaner's TagTransformation [1]2. reverse-proxy >> >> - reverse proxy servlet >> >> - no dependency on portlet api >> >> - using content-rewriter module >> >> >> >> 3. webcontent-portlets >> >> - portlet classes >> >> - using (or extending) content-rewriter >> >> >> >> 4. webcontent-war >> >> - portlet war >> >> - using all the other modules above >> >> >> >> Then I think we can reuse many good features of apa-webcontent in many >> >> scenarios.By the way, I would bump up the trunk version to 2.0 with >> moving >> >> the current trunk to a 1.x branch if there's no objection. (Also >> probably >> >> we'd better change the package name to >> >> 'org.apache.portals.applications.webcontent2' as well.) >> >> >> >> Do you have any objections or different ideas? >> >> >> >> Cheers, >> >> >> >> Woonsan >> >> >> >> >> >> [1] http://htmlcleaner.sourceforge.net/javause.php >> >> >> > >> > >> > >> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: jetspeed-dev-unsubscr...@portals.apache.org For additional commands, e-mail: jetspeed-dev-h...@portals.apache.org
