Gary,
UCM is already done for CLI from eBay
https://groups.google.com/forum/#!topic/joomla-dev-platform/sqdZ0B_WCiQ
SW
On 4/13/2012 9:38 AM, Gary Mort wrote:
I wanted to gauge interest here. I'm setting up my own personal
websites and I find:
Joomla! is 60% of what I want
20% of what I want can be handled with custom components, templates,
modules, and plugins
5% of what I want is either in the next platform or cms release
10% of what I want can be handled with autoloaders and overrides
5% of what I want requires hacking core code
Now, if I was my client, I'd tell myself to focus on what I /need/ not
what I want and try to eliminate any core hacks and most of the
overrides..
But I'm not a client, I'm me. And everytime I start setting this up I
get frustrated because it doesn't meet my artistic vision - and I'm
not willing to compromise my vision[wow, I sound like a silly
*artiste* don't I?]
So the solution is simple, fork Joomla!
Not in a competitive way, but in the way I've seen done on countless
client projects where they have some custom code they use in house and
no one else ever see's the code.
My plan is to create a fork of the Joomla! repository. Then in that
fork create 2 new branches, one for dev/hacks and one for
releases...ideally 80% of released code could be pulled right back
into Joomla!...and if it's pulled properly, when I update my fork from
their it will integrate seamlessly and override my own code.
My question is, how many people are truly interested in playing around
with it? Not just a cursory glance, but truly looking it over and
testing it out? Because my early code will often have stuff I don't
want publicly available, I'll be placing it all in a private github
repository...and I'm not willing to pay for that so it means charging
a nominal annual fee for repository access[say 24$/year to make sure
people are serious and make sure I don't end up losing money to
Github]. Almost everything there will....eventually make it out into
the public either as an installable Joomla! extension, or pull
requests back to the source.
As a quick summary of what I "want":
Multi-site single installation codebase: All Joomla needs is 2 changes
to support multiple domains from the same codebase. It needs a
hook/plugin for the query builder so a domain filter can be added to
when using specific tables[for example, where DOMAIN='mydomain.com']
and a pre-system setup call to set the domain. That is it.
Everything else is in there, plugins for editors can add the domain
selector. Plugins for forms can filter out domain specific info, etc.
Unified Content: Taking a leaf from Drupal, instead of storing raw
content in the content table, I'd much rather store content that has
already been formatted for display and is searchable. All it requires
is adding an content type mapping to map content to different
components for editing and in one swell fwoop you get rid of 90% of
the SEF headaches...SEF now can almost /always/ use content sef
mapping. Other components augment content rather then display
different content. It also solves 75% of searching issues as all
searching can be done on the content itself, not different searches.
Null Storage engine for Caching: Over and over in the codebase there
are all these components that store objects they retrieve so they
don't retrieve them over and over. But we already have a class that
does this, Cache....the only problem is that cache is for storing data
TO somewhere. But in this case, we only want to store data in
memory. So use cache.
Caching priorities: TTL SUCKS as a caching strategy. Basically it
says 'save this for 15 minutes, then throw it away'. As long as I am
caching data, I want it to be intelligent!
A typical Joomla! Caching snippet:
$cache = JFactory::getCache("com_mycomponent", "");
$cacheKey = $this->getId();
$item = $cache->get($cacheKey);
if (empty($item)) {
// do some stuff to get the item
$cache->store($item);
}
// do something with the item
How...wasteful. Why not:
$cache = JFactory::getCache("com_mycomponent", "");
$cacheKey = $this->getId();
$importance = JCache::HIGH;
$softLimit = '360';
$hardLimit = '3600'
$item = $cache->get($cacheKey, $importance, $softLimit, $hardLimit);
$p = JProfiler::getInstance(cacheKey);
$p->mark('Start');
if (empty($item)) {
// do some stuff to get the item
$p->mark('Stop');
$retrievalTime = $p->buffer;
$cache->store($item, $importance, $softLimit, $hardLimit,
$retrievalTime);
}
// do something with the item
Wow...NOW we have some metrics. We know how LONG an item took to
retrieve. All things being equal, objects with the same importance
should be expired based on the time they take to generate, not FIFO.
So if you have 2 objects and one takes a millisecond to generate, and
the other takes 1 minute[think an internal db call vs an external REST
call to grab a chart image from Google] - isn't it obvious which one
to throw away first?
And by using soft and hard limits, instead of simple TTL, we can keep
'stale' data until it gets updated. A stock price from Google is just
as valid an hour from now as 10 minutes from now - but maybe we want
to retrieve it every 10 minutes if possible, but will settle for older
data in some circumstances.
Lastly, passing the importance flag to the retrieval as well as the
storage allows different items to 'upgrade' cached data. Maybe it
wasn't important to one section of code, but another call on a
different page really needs the cached data if at all possible because
otherwise it bogs down.
Speaking of Cache... PHPSerialize is wonderful...if everything is
running PHP. But what if you have a caching proxy sitting up front?
For a stupid logon module, you destroy caching for logged in users
since the upper right hand corner of the screen changes from: Login...
to: Hello Gary, you have no new messages
A caching server could use esi:include
url="http://mydomain.com/userwelcome"; and cache everything else but
grab that info from the server. Even better though, since you have a
sessionid cookie, instead it could be:
src="memcache:get(sessionid->userwelcome)" and if the data is stored
in memcache with a sessionid in json format, poof! It appears. No
server hit needed.
And why should we lose the ability to count hits just for the sake of
caching a page? Almost every caching system today allows for that!
esi:include src="memcache:incr(<articleId>Hits)"
Sure you occasionally have to sync that data back to the
database....but its much more fun!
Just figured I'd throw it out there. If there is stuff others "want"
that would make them willing to pay $24/year for feel free to throw it
on the pile and if it's amusing enough it will probably get in there.
_______________________________________________
New York PHP SIG: Joomla! Mailing List
http://lists.nyphp.org/mailman/listinfo/joomla
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
_______________________________________________
New York PHP SIG: Joomla! Mailing List
http://lists.nyphp.org/mailman/listinfo/joomla
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
