[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [jfw] Validate, Filter, and Escape Package



Of course I strive to build agreement on Interfaces, that's why I moved all of my Interfaces out of the Molajo repo and placed them into an unbranded repo and listed them as packages on Packagist. I want to encourage sharing at that level for interoperability -- without having to "give credit."  I use all of those Interfaces - there are about 150 of them - as dependencies in Composer for Molajo.

However, it is not true that I advocate Interfaces _over_ concrete implementations. I advocate Interfaces _with_ implementations. In this package alone, I am using six interfaces. In one case, it allows developers to slide in their database package for a foreign key fieldhandler without creating a dependency on the one I am using. (Joomla's).

Even in my own application, I inject interfaces for my own packages, I never name concretes in my classes, only Interfaces. This is so that a dev could use the Molajito rendering package, for example, and whatever escaping option they want. Or, they can use my Event package with their plugin environment, etc. I've worked very hard to build in those flexibilities.

(Where I do use concrete references is in the factory model classes for the IoCC, but that's the plumbing -- and that's exactly where it would be changed if another concrete was preferred. The other place you'll see me naming concretes is in the fieldhandler where the proxy class creates the adapter class. For those "internal to a package" places -- it's okay because it won't be swapped out.)

Here is my frustration. You and I are talking about replacing InputFilter and OutputFilter with something that is easier to extend and updated in terms of PHP 5.3 filtering, etc. I'm offering my code. I'm doing a little analysis in the spreadsheet to map what I have to what must be replaced in the Joomla framework and trying to think about how we can cleverly avoid BC issues and test to ensure it continues to work as expected.

No, I do not believe most developers are not going to pick a framework or package that only has Interfaces unless they are building a framework. They aren't even likely, IMO, to pick a framework that makes good use of Interfaces. What they are more likely to do is select a package that helps them validate and/or filter and/or escape their data without a lot of fuss and do so correctly.

So, to hear you say let's just offer interfaces and everyone can code it their way -- well, Andrew, that may sound fabulous to you and me -- but most developers just want the code.  And no, I don't want to do it my way and have you do it your way. The Joomla framework just needs one solid package that can go the distance the next few years.

I do not care how we do it.

I don't even care if you want to do it yourself. I know what it's like to have a vision and have no choice but to lay the code.

But, I see no reason to have less than or more than one of these in the Joomla framework and I am willing to help but this is you guys architecture and you need to make some choices. I can help provide data or analysis for review, but it's not my framework. It's yours -- and I hope you guys have a vision of where you want this to go.

Here are the Interfaces I am using -- yes, I have filter, validate and escape separated. I also added a response object given the discussion here.

FilterInterface
ValidateInterface
EscapeInterface
Response interface (similar to v1 of FIG Cache)

I don't need flexibility in licensing. I know what Joomla requires. I have signed the agreement. I'm not asking for anything different. I'm not trying to be a library -- you can have raw code -- whatever you want or need.

If any of my code is useful it can be brought into the Joomla framework under the LGPL and changed. It will be treated like any other Joomla code -- OSM's copyright -- your coding standards, your code. You can delete it - restructure it - keep it as it is. I'm still family. Like it, or not. ;-)



On Fri, Apr 18, 2014 at 1:45 AM, Andrew Eddie <mamboblue AT gmail.com> wrote:
On 18 April 2014 12:23, Amy Stephen <> wrote:
> OK, I can see this is going nowhere.

What part of "why not just agree on an interface" don't you like? I
wasn't joking - that was a serious suggestion. That leaves the
implementation up to you (or me, or Don, or whomever), but anyone that
standardises on those interfaces is in a win-win position of having a
number of choices to work with. That would seem to be a logical first
step when there are at least two competing, but equally valid (I'm not
saying your way is wrong, it's just one option), coded solutions. I
seem to remember you advocating interfaces over implementation in the
past anyway.

And maybe I wasn't clear but it would be appropriate to list the user
libraries that implement these interfaces both as kudos to the
developers and helps the developer user find them. A nice side effect
is that you may also have more license freedom (can't wait to see what
our friend on twitter will make of that comment) but I'll play it safe
and stick to LGPL-2.1+ :)

/me is scratching his head wondering what just happened

Regards,
Andrew Eddie

--
Framework source code: https://github.com/joomla/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to a topic in the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-framework/HK9p1QaX6BA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.

--
Framework source code: https://github.com/joomla/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.