Page 1 of 1
Application extensibility
Posted: Mon Jan 08, 2007 6:52 pm
by alex.barylski
At the class level, this is well known and understood, in any language, but application level not so much...
I'd like to start a disscussion on how we as PHP developers could develop new applications which are extendable at an applicaiton level not just class level.
Allow me to get slightly more specific by stating that I am looking for ways to extend applications in the sense that modules are overridden *not* over written. OOP but at an application level.
Using callbacks/hooks is obvious, but can we think of unique instances or examples?
Remember, the impetus of this disscussion is extending an application without touching it's source code.
Cheers

Posted: Mon Jan 08, 2007 7:00 pm
by wei
i think you need to be more specific. Are you talking about disparate integration problems? Are you trying to extend, by adding features to, a legacy application? Are you trying extend, by changing the behaviour of, a library of code? Are you trying to extend, by changing the foundations of, a framework? Are you trying to extend, by allowing code reuse?
Posted: Mon Jan 08, 2007 7:14 pm
by alex.barylski
I'm not extending anything...it's purely a topic I've been investigating...in theory...
It's an application (application level?) not a foundation or framework of classes, like Zend, Smarty, etc...
An entire application...
I have a CMS and a phpBB setup...both use separate logins...it's not always easy to integrate the two...assuming you could in theory, redesign the both to be completely independant systems and yet communicate easy when both installed.
I'm not looking for techniques to refactor existing codebases or modifying existing systems. Rather theoretical techniques or methods in building extendable entire applications...
Posted: Mon Jan 08, 2007 8:16 pm
by Christopher
Given what PHP application actually do, I would thing that modules and plugins would be the two main schemes. Modules would be discoverable units with a defined interface, but definitely autonomous units. Plugins fit into a defined interface and modify or replace some part of the application. The framework would provide the "inheritance" by providing existing functionality that can be reused.
Posted: Tue Jan 09, 2007 12:08 am
by wei
I have a CMS and a phpBB setup...both use separate logins...it's not always easy to integrate the two...assuming you could in theory, redesign the both to be completely independant systems and yet communicate easy when both installed.
then, in practise, this is probably an integration problem. One possible solution is to expose some of the API of both application as services (not necessarily web services) and glue them together somehow (the somehow is the trickier part).
I'm not looking for techniques to refactor existing codebases or modifying existing systems. Rather theoretical techniques or methods in building extendable entire applications...
build from the beginning? good in theory to build from scratch but impractical due to resource constraints in most cases. Also, very difficult to know which parts should be "extendible" unless you have some in-depth domain knowledge.
getting towards the application design level, may be some form of dependency injection (DI) could be used. Allowing your application to be able to use dependency injection is, i think, quite tricky to retrofit. May be if the development process includes TDD and uses Mocks extensively, the resulting application is more fitted to use DI?[/quote]
Posted: Tue Jan 09, 2007 12:32 am
by timvw
I think it's essential to define good contracts between applications that want to inter-operate... It usually also involves writing mappers to get the data as defined by the contract in a such a way that it makes sense in the domain of your application.. Because the existense of such contracts applications can both upgrade/change independently...
Posted: Tue Jan 09, 2007 12:45 am
by matthijs
And what about RESTful applications? They have a completely extensible API which can be use to do almost anything to the data (in a CRUD like app). If you want you can write another application on top of that which does something completely different with the data.
For example if I have a book library one of my routes is /books/horror/isbn/234455 (gets that book). This route can be used by another app to retrieve the book and do something with it. With the right authorities, even update the book.
Just thinking a bit, I've no experience with this.
Posted: Tue Jan 09, 2007 10:56 am
by alex.barylski
matthijs wrote:And what about RESTful applications? They have a completely extensible API which can be use to do almost anything to the data (in a CRUD like app). If you want you can write another application on top of that which does something completely different with the data.
For example if I have a book library one of my routes is /books/horror/isbn/234455 (gets that book). This route can be used by another app to retrieve the book and do something with it. With the right authorities, even update the book.
Just thinking a bit, I've no experience with this.
Did a quick Google for RESTful found something on CPAN, read a bit sounds interesting...
Have any good resources?
Posted: Tue Jan 09, 2007 11:15 am
by Kieran Huggins
The concept of REST can be applied to more than just URLs - the system I'm writing now loads everything into a DOM-like-structure, which is in turn available to every part of the app, modules and all. From there, the resulting XML is transformed via XSLT to whatever output is required (rss, xhtml, etc...).
This is RESTful in the sense that every data model has a published XML structure, so any module can simply query that structure with XPATH.
Is that the kind of thing you're looking for?
Posted: Tue Jan 09, 2007 11:47 am
by matthijs
A very good article from Maugrim,
http://blog.quantum-star.com/index.php? ... ework.html. However, his site is out of the air at the moment... Google cache still
has it though.
Another good article is
http://www.peej.co.uk/articles/rest
Posted: Tue Jan 09, 2007 1:02 pm
by Christopher
matthijs wrote:For example if I have a book library one of my routes is /books/horror/isbn/234455 (gets that book). This route can be used by another app to retrieve the book and do something with it. With the right authorities, even update the book.
It is interesting because one of the results of REST is to abstract the request strings which can make them more application/module independent. As ever, defining the interface is paramount. REST focuses on the interface for the request/response cycle and presents a clean solution for defining those interfaces.