Input filters in Revo

Ok, can you give an example of an input filter used in a tag?

Quote from: BobRay at Jul 12, 2009, 05:57 PM

Ok, can you give an example of an input filter used in a tag?

Sure, though it might be better to discuss it as a "Filter" with an input part and output part that are coordinated, since the input filter is just there to help prepare for what the output filter is going to do (i.e. the input filter simply defines what output filter to execute along with any other details it needs):

The input filter here is nl2br, which essentially defines that the output filter should execute the nl2br modifier to transform the output.

Hi Bob,

In 096x output Widgets became output filters. Just to be sure are you making the same assumption that input filter in Revo is the same as the input widgets?

If that’s not the case, then perhaps it may make sense to just simplify the term to "filters" to prevent similar confusion. Even the nl2br example takes me actually concentrating on it to think through, because the "one" nl2br filter is actually comprised of two filters on the input and output side. "Filter" would just be the aggregate representation of what happens to something, and it can affect the input, output or both of a TV in the front end.

Or should I just go away?

Quote from: rthrash at Jul 13, 2009, 01:09 PM

Hi Bob,

In 096x output Widgets became output filters. Just to be sure are you making the same assumption that input filter in Revo is the same as the input widgets?

If that’s not the case, then perhaps it may make sense to just simplify the term to "filters" to prevent similar confusion. Even the nl2br example takes me actually concentrating on it to think through, because the "one" nl2br filter is actually comprised of two filters on the input and output side. "Filter" would just be the aggregate representation of what happens to something, and it can affect the input, output or both of a TV in the front end.

Or should I just go away?

We are certainly not talking about widgets in any shape or form. We are talking about the new features of MODx Revolution’s Element class, which allows you to define Input Filter and Output Filter classes that are applied before and after processing of an Element respectively. By default, modInputFilter and modOutputFilter are applied to all elements and provide functionality almost identical to PHx. Core extensions could provide different implementations for these, though that will be a more advanced topic. Never-the-less, the distinction between the pre-processing/input and post-processing/output filters are important for developers to understand.

Again, this has no relation whatsoever to Template Variable widgets.

Let me make it clearer where I’m coming from. I started here: http://svn.modxcms.com/docs/display/revolution/Input+and+Output+Filters and then looked at the code in modoutputfilter.class.php and modinputfilter.class.php.

I get that you’re saying that nl2br in a tag triggers both input and output filters, but I think this may be one of those cases where we have to sacrifice a little accuracy in order to make things understandable to new users (like on the docs page above). In the docs above, nl2br is listed as an output filter (which, I believe it is). If input filters and output filters are different things, it’s probably not a good idea for nl2br to be both. IMO, the only built-in input filter is the one in modinputfilter.class.php. Output filters need names in order to be usable so I’m thinking nlbr is the name of an output filter.

Maybe Ryan is right that we should just use the term "filters" in "how to" documentation, but I think I’d prefer to use nlbr, ucase, tag, etc. as the names of output filters and say that the default input filter parses tags for use with the named output filters. The default input filter seems to do a pretty good job and I can’t imagine that many users will want to modify it or add a custom input filter, so I’m wondering how much needs to be said about input filters except to very high-level developers. Maybe there’s a more common use for custom input filters that I’m not aware of.

Are custom input filters possible without altering the core code?

I agree we need to refer to them generically as filters (inclusive of input and output) in user-oriented documentation, but this points to the urgent need to separate the documentation for developers from those for others. I refuse to oversimplify developer documentation to make it easier to understand for those not interested in development. Sacrificing developer knowledge and potential innovation that comes from a clear understanding of the implementation is not at all acceptable IMO, or no one ever will extend the default filter implementation.

Absolutely agree there Jason and think that’s the right approach (dev vs end user).

I don’t think I’m suggesting oversimplification, even by your definition (although we probably disagree on the dividing line between "simplification" and "oversimplification"). Nor am I suggesting inaccuracy (at least not intentionally).

I’d like to call the filter triggered by the case: lcase statement in modoutputfilter.class.php *something* so it has to have a name. I was suggesing calling it the "lcase output filter" since It modifies the output of the tag it’s included in and operates after the tag is processed. Calling it the "lcase filter" would be *less* accurate, IMO. On the other side, I’d like to call the filter in modinputfilter.class.php the "default input filter." I don’t think that’s oversimplifying anything. This scheme is my first choice because I think it best captures what these things are and is easy to understand. (Although I’d argue that the default input filter is actually more of a parser than a filter.)

My second choice, which you might like a lot better and I could definitely live with, would be to say we have one default input filter and one default output filter with many "modifiers." In that case, we’d have the "lcase modifier." I concede that "modifier" is a little more accurate than "filter" for these things and that it’s more accurate to say that the two class files each contain one filter. That would leave the question of custom filter snippets -- should they be "custom filters" or "custom modifiers" or something else?

Am I making any sense here?

Sorry, yes, you are making sense; those are, in terms of the default filter implementation, indeed referred to as "modifiers", and we should maintain that identity since it was nothing more than a conversion of the existing PHx modifiers, though even I am not clear on the distinction between PHx "commands" and "modifiers". IMO, we just keep it simple and refer to them as "modifiers".

I was simply suggesting that we need to keep the distinction between Input and Output Filters, not the specific "default" implementation of them, which involves the use of these "modifiers".

Quote from: OpenGeek at Jul 13, 2009, 07:40 PM

Sorry, yes, you are making sense; those are, in terms of the default filter implementation, indeed referred to as "modifiers", and we should maintain that identity since it was nothing more than a conversion of the existing PHx modifiers, though even I am not clear on the distinction between PHx "commands" and "modifiers". IMO, we just keep it simple and refer to them as "modifiers".

I was simply suggesting that we need to keep the distinction between Input and Output Filters, not the specific "default" implementation of them, which involves the use of these "modifiers".

Fair enough. I never meant to blur the distinction between Input and Output filters; sorry if I wasn’t clear about that. I also should have noticed the "modifier" usage in PHX earlier.

I’ll call the custom output filter snippet thingies "custom modifiers" to match the PHX docs.