On 2/11/02 4:57 AM, "Daniel Rall" <[EMAIL PROTECTED]> wrote:
> Jason van Zyl <[EMAIL PROTECTED]> writes: > >> On 2/9/02 1:49 PM, "Daniel Rall" <[EMAIL PROTECTED]> wrote: >> >>> First off, let me say that I am not against the idea of a "selector" >>> for multiple pipelines. It's just the suggested implementation that I >>> have issues with. >>> >>> Even though I don't think that even optional pipeline capabilities >>> should be programmable from XML, I will not -1 its inclusion (on an >>> optional basis). However, I will not support promotion of such >>> facilities in the Turbine documentation >> >> What does that mean exactly? You won't write documentation yourself >> promoting this method, or that you will prevent someone else from doing it. >>> From the tone it sounds like the latter. > > The latter. But after talking with James on IRC, it looks like our > ideas are actually much closer than I had first thought, so much so > that I was able to take his base Valve and easily subclass it from my > branch point suggestion. It's good that you actually discussed the idea with James, but the reason I prodded was more of a policy issue. Are we all to practice the philosophy of preventing documentation being issued on methodologies we don't agree with? What one person views as a best practice is often not entirely congruent with what another views as a best practice. I'm an ardent believer that actions, and flow in general, should not be accessible from templates but it's a practice that exists and a methodology that certainly is documented. You tried to provide a alternative to James' first proposal whereas I haven't provided an alternative to the control flow in templates but when I have do you think it would be a fair position for me to try and prevent $link.setAction(x) from showing up in the documentation? I certainly think that would be a bit heavy handed. If someone wants to put immense quantities of logic in their templates, or someone wants put logical indicators in their pipeline descriptors then so be it. If they want to document it and people use it to get a job done how can documentation hurt? And how would preventing documentation on a particular methodology, even if highly disliked by certain parties, help anyone? > Dan > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
