portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Taylor <davidseantay...@gmail.com>
Subject Re: APA-WebContent Refactoring
Date Fri, 17 Jan 2014 16:06:29 GMT
>  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

On Thu, Jan 16, 2014 at 4:19 PM, Woonsan Ko <woon_san@yahoo.com> wrote:

> Hi David,
>
> Thanks for the quick response!
>
>
> On Thursday, January 16, 2014 9:58 PM, David S Taylor <
> david@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
> >david@bluesunrise.com
> >
> >
> >
> >
> >On Thu, Jan 16, 2014 at 11:28 AM, Woonsan Ko <woon_san@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
> >>
> >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message