[sakai2-tcc] Filtering Content served from CHS

[Aaron Zeckoski]

On Fri, Dec 10, 2010 at 11:14 AM, Matthew Buckett
<matthew.buckett at oucs.ox.ac.uk> wrote:
> On 10 December 2010 16:00, Aaron Zeckoski <aaronz at vt.edu> wrote:
>> Ah, OK, so here is the use case I have in mind.
>> -----
>> I am system admin (or tool writer) and I need to add a custom bit to
>> the top of every page (like some CSS or JS). I don't want to have to
>> rebuild the system just to add a JS or CSS include but I can probably
>> manage something fairly straightforward like a provider or a config
>> option.
>> -----
>
> Just to be clear I am only suggesting filtering content served from
> CHS, this is not a generic filter solution for Sakai for portal or
> tool requests.

I fully understand this is only for resource content.

However, you have to realize that most users don't think of resource
content as being outside the system/portal (even though the way it is
rendered, it is). I am trying to suggest a way to possibly bridget
that gap.


>> It seems like something like this where I might create a filter and
>> include it with my tool would work EXCEPT that my filter might be
>> ignored.
>
> It up to the filter to decide if it wants todo anything, all the
> filters get asked if they want to filter the output and then those
> that do get to wrap the response.
>
> m_outputFilters  is List<ContentFilter>
> res is HttpServletResponse
>
>                                        for (ContentFilter filter: m_outputFilters)
>                                        {
>                                                if (filter.isFiltered(resource))
>                                                {
>                                                        res = filter.wrap(res, resource);
>                                                }
>                                        }
>
>
> At the moment there isn't a provider interface to register filters
> from outside the kernel, but there could be.

I think it would be necessary to allow configuration from outside the
kernel. As a general practice, we should not be adding things that
would require a kernel rebuild in order to customize them.


>> Then I get to spend hours explaining to people why the filter
>> I provided won't work with some other filter they made locally or
>> another filter provided by a 3rd party.
>
> Yep, but I think that's the better way todo it.

Spending hours explaining the situation to each person that tried to
use my tool is the better way to do it? I don't think I can agree on
that point.


>> Maybe this needs a different solution where we setup something in the
>> portal and the default filter here will also respect the stuff the
>> portal is using but a system where my part that I added might just be
>> ignored seems like a maint nightmare.
>
> The portal doesn't serve up content out of CHS. So I'm slightly confused.

Yes, I know. This is a bit of a problem as I mentioned above. I am
hoping this will help bridge that gap and correct the problem.


>> Also, that detection of already provided stuff seems like it could be
>> a real pain when/if it fails and would be a maint burden on the core
>> Sakai team.
>
> What do mean "already provided stuff".

This:
"Yep, firstly my current implementation checks so would only append the
top/tail if it doesn't see one already."

-AZ


-- 
Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile