Thanx Alex! Great review.
IMO good starting point to discussions about parts of PP...
You point directions:
Events framework, Modular separation of code, Organised file
structure, ACL, Project Config, Unit tests, Caching
My next 5c - templating (theme layer)
Overview of this tasks lead my thoughts to different.
PP already got good ORM but it needs little bit changed to be more
modular. From this point we need to change core or ORM. At this moment
suppose it is subject-driven but you talk about event-driven ORM. It's
a thinest place of paradigm - architecture! We need more opinions
about!
For example: posting a task. Task class should notify about it's
creation, latter task obj should notify about editing insertion and so
on. Today we add functions to task class to call other objects and
methods. In Alex's proposal we need parent class which already got
methods to subscribe on object events (is it event subscribing?).
Another way 'drupalish' - hook somelike as events but there's no
subscribers just look whole namespace for patern-functions - this way
is flexible but brings a lot of memory scans for function names
(drupal 7 now have a registry of events).
Next a file structures - depends on Architecture. ACL, Config, Caching
is a superclasses there implementations can store data bypassing to
data-layer in different backends.
Render-theme-template should be a pluggable suppose some kind of view as pp has.
Cons: let's take a closer look at current architecture with all +&-.
Most of classes alredy implement whole functionality so we need review
current MVC model and maybe code some abstract classed and pluggin
gates.
Waiting for opinions!
Andy
2008/8/8 Alex Mayhew <[EMAIL PROTECTED]>:
> Time to bump this thread a bit ;)
>
> Andy Postnikov wrote:
>
> Again and again... A lot of thoughts about ways but what are we talking
> about?
>
> Proposal to rewrite? What is a target? new features, speed and new bugs...
>
> Ok, here are some ideas I've been thinking about, most of them are based on
> what Ryan outlined in the roadmap email
> This is a selection of features which pp desperately needs:
>
> Events framework
>
> To allow developers to interact with PP at specific intervals without having
> to hack the core / other components
>
> Modular separation of code
>
> To enable developers to package code as 'modules' so that they can reuse
> their code / share it with other developers
>
> Organised file structure
>
> Files should be separated into their respective groups i.e. -
>
> System
> Helpers
> Libs
>
> Application
> Controllers
> Libraries
> Vendors
> ....
>
> Modules
> ....
> ....
>
> etc.
>
> Allows for overloading of core components
>
> ACL
>
> Move permissions out of the models and into a library / dedicated model,
> current implementation is too spread out
> Should allow permissions to be added dynamically
>
> Unit tests
>
> Allows developers to see if changes they make break the core
>
> Project Config
>
> Mainly for 'system' use, would allow developers to control config on a per
> project basis
>
> CACHING!!
>
> PP is currently terrible at caching - it only caches objects for the
> duration of a request.
>
> And here is one that I feel would be beneficial (but not 'necessary' for the
> project)
>
> "Friendly urls"
>
> Would allow emulation of basecamp api, which would allow pp to integrate
> with many products such as beanstalk, freshbooks etc.
>
> Tim has made a friendly urls patch which does part of this - it translates
> {project_id}/{controller}/{action}?{params} to index.php?c={controller.....,
> although parameters are still passed through a query string
>
> At this point, I try to assess the decision using a few questions:
> 1) What does this gain/provide us with? or what problem does this solve?
> 2) What does this restrict or lose us? also, What does this cost?
> 3) Are there any other ways of achieving this? and their related merits.
> 4) Is this in the best interest of the community/project? and is this
> what the community wants?
>
> First of all...
> 1) It brings a lot of new bugs. Solve some old problems but ...
> 2) loose compabillity, restrict in support older versions, brings a
> lost of old customers and hard way of invit new. Cost is not cheep but
> suppose very high!
> 3) Many ways...
> - but first to document current code some way...
> - then draw architecture and bottlenecks
> - review code (mostly done)
> - and only then make proposals! and costs :)
> 4) What purpose of Community? Bring bugreports & patches, answer a
> support questions, collect opinions of features
>
> We write the code, we know what's going on and why. We will be able to fix
> a number of current problems (timezone support springs to mind)
> We lose backward compatibility with previous versions, then again we can't
> keep supporting old versions forever else we will never progress. It would
> obviously require time to rewrite the entire project, however it's not as if
> we are currently using that time to develop pp as a team
> Yes, there are two:
>
> Refactor the current codebase
>
> We keep our 'identity' as a standalone application and have no dependencies
> on third party apps (barring vendor libraries)
> All the core functionality is present (i.e. tasks, milestones), we just need
> to make it extensible
> However, if we make a change we have no idea what the repercussions will be
> as we don't know what references it (unless we use a global "find /
> replace")
>
> Rewrite PP
>
> We can selectively include / exclude features
> We "know" the code
>
> The "community" want need to be able to customise and extend pp. At the
> moment customising involves modifying core files and making sure you carry
> over the edits when you upgrade. If we asked the community "Shall we
> rewrite PP" I imagine most wouldn't mind too much - They just want something
> that works, but don't really care how as long as they can upgrade easily.
> Those who have hired developers / invested time to customise their current
> installations will be a little peeved at the concept of having to recode all
> their modifications to work with a rewrite, although I'm sure they will be
> able to see the possible benefits of upgrading. Finally, there will be
> others who think that we should stick with the current codebase. The main
> purpose of the community is to test PP, submit feature / bug reports and if
> they are able to, patches.
>
> Alex
>
> side note - @Ryan, shouldn't the 3rd party libraries be svn:externals so
> that they can be kept up to date easily?
>
> --
> Usually something witty would go here, but as I'm the sort of guy who
> doesn't have a catch phrase I'm afraid this is nothing but more than ultra
> boring rubbish - which you've been suckered into reading :P
>
> No virus found in this outgoing message.
> Checked by AVG.
> Version: 8.0.138 / Virus Database: 270.5.12/1597 - Release Date: 07/08/2008
> 05:54
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Projectpier-development mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/projectpier-development
>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Projectpier-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/projectpier-development
