A common package of interfaces

202 views
Skip to first unread message

Brandon Savage

unread,
Aug 15, 2014, 12:45:01 PM8/15/14
to aur...@googlegroups.com
One of the chief goals of the Aura project is the concept that the packages are independent of one another. I can use the CLI package without being required to use the DI package or the SQL package. This is a huge advantage of Aura over its competitors (like Zend). However, it leads to some code duplication that is best avoided.

For example, we have Aura.Session, but we also have Aura.Auth which handles sessions on its own. Aura.Session is incompatible with Aura.Auth.

We have Aura.Filter, and we also have Aura.Input. Both will filter/validate content, and both do some of the same things, but they are incompatible with one another.

It seems to me that there are ways we can improve upon this. One of the ways would be to create a library containing nothing but interfaces for common behaviors (like sessions, database handling, filters, etc.)

This would not violate the principle of decoupled packages, because a library of interfaces doesn't actually do anything. It simply defines the rules by which certain operations are performed. Then, a person using the Aura.Filter package can swap the filters in Aura.Input, or someone using the Aura.Auth package can use their existing session configuration.

Thoughts?

Brandon

Hari K T

unread,
Aug 15, 2014, 10:05:12 PM8/15/14
to aur...@googlegroups.com
Hi Brandon,

Nice to see email to the list. I will write what I feel inline.

One of the chief goals of the Aura project is the concept that the packages are independent of one another. I can use the CLI package without being required to use the DI package or the SQL package. This is a huge advantage of Aura over its competitors (like Zend). However, it leads to some code duplication that is best avoided.

I agree, but I do think that is not much code.
 
For example, we have Aura.Session, but we also have Aura.Auth which handles sessions on its own. Aura.Session is incompatible with Aura.Auth.

We have Aura.Filter, and we also have Aura.Input. Both will filter/validate content, and both do some of the same things, but they are incompatible with one another.

A simple filter is there in input. I agree, but they just need to implement a FilterInterface .

At the same time I wonder whether it will be good to remove the simple filter and promote Aura.Filter in Aura.Input . So people don't get confused or integrating will not be trouble.

When I say integration one concern to me is every package is independent on its own. ie great. But that leads to complexity in integration. Aura could have provided bundles in the core.

Eg : When we try Input , Filter, View, Intl, Html we will understand the time spend is lot. I would like Paul to strongly look into integration of the packages.
 
It seems to me that there are ways we can improve upon this. One of the ways would be to create a library containing nothing but interfaces for common behaviors (like sessions, database handling, filters, etc.)

I don't think we need interface as a separate package. As you can see Aura.Input and Aura.Filter can be integrated easily so does many of the components like Session and Auth.

So keeping an interface to be downloaded if they just forked a package without composer will be a bad idea or (may be not so good) .

As I mentioned the main concern is integration. So I wish aura to bring the bundles in core so we can promote use this bundle which have everything that can do the functionality.

Writing https://leanpub.com/aurav2 , I feel there is some pain especially for newbie to start with aura for there is none integrated and all are standalone. So I am trying my experiments on building the framework with all integrated in the core

http://github.com/cocoframework/

There is still some other concerns to me. But before I share I want to see how it can be resolved.
 
This would not violate the principle of decoupled packages, because a library of interfaces doesn't actually do anything. It simply defines the rules by which certain operations are performed. Then, a person using the Aura.Filter package can swap the filters in Aura.Input, or someone using the Aura.Auth package can use their existing session configuration.

I feel I have mentioned to these also above.
 
Thoughts?

I will hear what others have to say.

Thank you

Hari K T

You can ring me : +91 9388 75 8821

Skype  : kthari85
Twitter : harikt

Hari K T

unread,
Sep 13, 2014, 9:33:28 AM9/13/14
to aur...@googlegroups.com

For example, we have Aura.Session, but we also have Aura.Auth which handles sessions on its own. Aura.Session is incompatible with Aura.Auth.

We have Aura.Filter, and we also have Aura.Input. Both will filter/validate content, and both do some of the same things, but they are incompatible with one another.

It seems to me that there are ways we can improve upon this. One of the ways would be to create a library containing nothing but interfaces for common behaviors (like sessions, database handling, filters, etc.)

This would not violate the principle of decoupled packages, because a library of interfaces doesn't actually do anything. It simply defines the rules by which certain operations are performed. Then, a person using the Aura.Filter package can swap the filters in Aura.Input, or someone using the Aura.Auth package can use their existing session configuration.

Thoughts?

After thinking about this for a while, I am agreeing with Brandon for interface.

Paul what is your thought on this ?

Brandon Savage

unread,
Sep 13, 2014, 9:45:21 AM9/13/14
to aur...@googlegroups.com
The idea here isn't actually new. Laravel had a similar thought with their contracts repo. 

Sent from Mailbox


--
You received this message because you are subscribed to the Google Groups "The Aura Project for PHP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to auraphp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Paul M. Jones

unread,
Sep 13, 2014, 9:50:23 AM9/13/14
to aur...@googlegroups.com
*If* (a big "If") we were to do this, I would opt for one interface package per set of functionality. Aura.Session_Interfaces, Aura.Filter_Interfaces, etc. (Obviously, changes in one would require mirrored changes in the other.)


--
Paul M. Jones
pmjo...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
http://mlaphp.com



Hari K T

unread,
Sep 13, 2014, 9:55:20 AM9/13/14
to aur...@googlegroups.com
*If* (a big "If") we were to do this, I would opt for one interface package per set of functionality.  Aura.Session_Interfaces, Aura.Filter_Interfaces, etc. (Obviously, changes in one would require mirrored changes in the other.)

I am ok with one interface :-)  .

Hari K T

unread,
Nov 15, 2014, 5:36:51 AM11/15/14
to aur...@googlegroups.com
Hi all, 

It is more than 2 months... too bad that this proposal didn't got any lights.
 
*If* (a big "If") we were to do this, I would opt for one interface package per set of functionality.  Aura.Session_Interfaces, Aura.Filter_Interfaces, etc. (Obviously, changes in one would require mirrored changes in the other.)

I am for a big IF .

Paul, please consider creating  interface for single package as you like.

We don't need to replicate some of the functionality in two libraries. I am getting against this.

Integrating is really a hard problem . If things are not getting easier with components a few tight coupling is not a trouble.

Eg : I have been trying the integration of Aura.Auth and Aura.Session over https://github.com/friendsofaura/FOA.Auth_Session_Bundle .

I wish if aura could help people a seamless integration of components it will bring more users. Else integrating of the components are taking hours which users can write their own library than looking and learning code.

So I strongly belive shared interfaces will bring easy integration of many of the components .

Please consider.

Better late than never for we are in Beta2 of the Session and Auth.


Thank you.

Hari K T

unread,
Dec 30, 2014, 9:17:15 PM12/30/14
to aur...@googlegroups.com
Hey Paul, 

It is been quite some time.
 
*If* (a big "If") we were to do this, I would opt for one interface package per set of functionality.  Aura.Session_Interfaces, Aura.Filter_Interfaces, etc. (Obviously, changes in one would require mirrored changes in the other.)

Before we push another beta for Aura.Auth , Aura.Session , Aura.Filter etc I wish we could split and move on with single interface.

It is becoming harder when integrating different libraries when they all need to implement certain interface and we are duplicating the code whether it is small or big .

Please consider than too late.

Thank you

Hari K T

unread,
Feb 8, 2016, 10:03:58 AM2/8/16
to The Aura Project for PHP
It is been quite some time.

https://github.com/auraphp/Aura.Filter have not yet released 2.0 stable. Before a stable release can we have a common interface for the Filter ?

This will help for 2.x version of Aura.Input as we move on.

Chris Johnson

unread,
Oct 9, 2017, 4:26:21 PM10/9/17
to The Aura Project for PHP
Sure would be nice if Aura.Auth's session implemented the same interface as Aura.Session's.  As it is, one cannot easily use both packages together in the same application without forking the Auth library.
Reply all
Reply to author
Forward
0 new messages