NYCPHP Meetup

[Scott Wolpow]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/joomla/attachments/20120413/c1d720d2/attachment.html>