Hello Gaetano! Sorry, you're reading this email for the second time because i did not click the "reply to all" button.
On 12/20/08, Gaetano Giunta <[email protected]> wrote: > James PIC a écrit : > > Introduction > > ============ > > > > The goal of FrameworkTols component is to give users a basis for such > > architectures for web applications written in PHP 5. > > > Sorry, I have really no clue about what an optimal "basis for web applications" architecture is. Is this not overly broad in scope? What limits do you require? > > > > The compononent shall not provide a fully featured implementation of a > > SoftwareFramework_, but should help users to easily create their own, > > custom implementations. > > > This is a general tenet of the ezc library so far, but I fear that a good part of end users (ie. coders) appreciate more a good working component rather than a meta-component that allows them to build their own, after they have had to learn the meta-api. There was a good article about that on php-Architect a while ago, I think they called it "junctions" Actually, you're very right, that's the scope of the Tiein components. > > > > There are two ways to develop a SoftwareFramework_. > > > > Way 0: Develop and factorize > > ---------------------------- > > > > Develop an application, factorize into re-usable libraries (Django). > > > > In this case, power users can be rapidely confronted to limitations such as > > lack of factorization, and the need to either: > > > > - do the decoupling himself and patch the framework, maintain his branch until > > the patches are accepted upstream, if ever. > > - re-invent what is already implemented in a "contrib" application. > > > > The need for BC break is also encountered when updating the framework with > > this kind of process. > > > > FrameworkTools should make it possible for the user to maintain a framework > > without causing any BC breaks. > > > > Way 1: Study needs and implement > > -------------------------------- > > > > A correct study of the needs allow to implement the SoftwareFramework_ with > > proper object-oriented design in the first place. > > > > There should not be any factorisation left to do, BC breaks are then > > optionnal. > > > Wishful thinking. As in developing a software projects with correct and complete requirements since day 1. Agile practices mean "be prepared to refactorize" and learn to do fast/good, it does not mean prepare the final-framework-to-life-the-universe-and-everything. Yes, i'm refering to examples such as Django's ChangeList controller, which allows to build a custom dataset table in the Admin app. Unfortunnately, it's un-usable as-is outside the admin app. It turned out very easy to decouple as you can expect. And, this is not a final-framework-to-life-the-universe-and-everything-to-kill-all-kittens-and-rule-the-world, thrust me :) > > > > The need > > -------- > > > > Data driven applications > > ```````````````````````` > > > > Java is still in the hype for most projects that are valuable to software > > developers, > > > Java is on the way out. It is not an agile enough language, and it shows everywhere, especially in all features that have been tacked onto it with every new release, starting with collections, going through generics etc. Now you have the reason why i wrote "is still" for "most projects". > > design patterns like `Naked Objects`_ allow to build a data driven > > application with high overhead but low cost. > > > I am not knowledgeable at all about "naked objects", but something I know is: > Java had javabeans years ago. Everybody thought it would be the best way to build web-applications since frontpage, and humongous application servers where created based on the J2EE architecture. > Then one day everybody figured out that the overhead of javabeans was huge (as in dev time and runtime perfs), and the saving (as in developer time) where meager. So they 'invented' POJOs to get agility back into the language. > > SAP also has a flexible data model architecture, with the need to adapt it to every customers requirements. It is the worst pos sw I have ever seen. > Although my opinion about POJOs is off topic, feel free to have a look at a design doc done for another project, which is attached. > > Design requirements > > =================== > > > > This section summarizes the requirements. > > > > No dependencies > > Allowing users to define a data structure OAOO_, > > > OAOO is good. But waht is really better is "2 WAY design". > This means being able to > - use the tool to generate definitions > - use the tool to reverse engineer existing db/objects to generate the definitions That should indeed be explicitly added to the requirements! > and especially > - be able to alter your definitions at one end of the chain and have the tool incorporate the changes propagating them to the other end. IMHO: - Propagating changes means, re-writing tests fixtures, which means that the testing pattern has flaws. - There should not be any changes to propagate IMHO. Thanks a lot for your input, i'll fix the requirements asap and re-post it. Note that the above document might not be clear, because i actually reversed the needs i had when i wrote something else that seemed valuable enough to be proposed as a component. This means i've got an example design document that comes with the above requirements documents, i don't think it's a good idea to post it, is it? Regards, James. -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
