By dman on

In regards to a previous discussion on 'XMLNode' I've been looking at using the 'filters' mechanism to do XSL processing.

... And it works, sort of.
I created a filter definition (easier than I thought)
I declared it as an input filter (which isn't where I want it to go, but seems to test well)
And I can paste in raw XML content, and it displays as parsed results.

... but the parsing happens each time! The raw source is saved raw (which is actually a fantastic feature) but this is not what I wanted or expected. Is there a way to apply an IMPORT filter, not an EXPORT one?

Seeing as my target is not in fact to apply the filter to the input textarea, but to content from other sources, would I be best to branch the 'filter' concept into a whole other interface to administer the pipeline similar to that described by gjost?

Specifically, what I've got so far is an XSL that scrapes & converts HTML pages (head, meta & all) to a structure like the import/export module produces, which is then ready to be made a node.
I want to tune the pipeline (which will be needed for different pages coming from different layout schemas) and I think cascading filters will be cool for this, but then again, they may not be approriate, expecially seeing as I am wanting to end up with structured information, not just a string.

Should I define my own interface, modelled on, but independant of the existing filter() mechanism? Or should I try to twist it into doing something it had never conceived of?

.dan.

Comments

Steven’s picture

Steven commented

This is probably not what you're after, but even though filtering in Drupal happens on output, there is a caching mechanism for performance. If you then display the nodes using the standard viewing API calls, it will use this cached copy.

If you set your filter to 'no cache' during development, try turning it off. Note that you will need to re-enable your filter in the input format to reset the cache flag.

Also note that it will be your responsibility to clear the filter cache when your settings (or XSL) changes. Look at filter_admin_delete() to see how to do that.

--
If you have a problem, please search before posting a question.

dman’s picture

dman commented

I had caching totally cleared for my dev work (which is why I saw it processing each time) but it's handy to know.

I'm thinking I will have to go my own way for this, and other reasons. My transformation pipeline will actually have to be more advanced than the current filter cascade, as I will want to put some conditionals into it too : if the input has a div id='content' use this XSL, if it has input div id='body-copy' use another etc.

(yeah, lots can be done inside XSL, but it gets messy, and I'd rather have it modular)

I guess I'll pick the bone of the filter functions (I like the interface, and advanced filter options) and come up with something new.

Thanks.
.dan.

.dan. is the New Zealand Drupal Developer working on Government Web Standards