[sakai2-tcc] Filtering Content served from CHS

[Matthew Buckett]

On 10 December 2010 16:29, Aaron Zeckoski <aaronz at vt.edu> wrote:
> 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 it's not a good solution to expose this outside the core kernel then?

>>> 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.

I still don't understand how adding a modifying the content will
bridge the gap, or what you mean by bridge the gap.

>>> 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."

It could be, our production experience is it hasn't been, but then
maybe people haven't noticed.

-- 
  Matthew Buckett
  VLE Developer, LTG, Oxford University Computing Services