[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [jfw] Re: Discussion - Framework v2 Roadmap



Cache indeed needs storage to do its job, but it is not just that, it has numerous functions that come on top of storage the same with databases, you can't degrade them both just to storage, it's like you would say car is the same as engine.
Examples of such functionalities of caching package that separate it from what I would cosider pure read/write storage: expiration control, id management, auto garbage cleaning,and convenience functions for on-demand management. Controllers are coupled with application and should be part of application library as Michael suggested, with the possible exception of function/callback cache which is usefull in wide array of applications, here I would +1 on top level interface.

But indeed having a common storage package is a must, such package would be implemented not only by database or cache, but also by session. And for filesystem - +1 for storage adapter.

Cache            >                
Database        >   Storage  >  Filesystem
Session          >

One more suggestion for Input. This is more application stuff, but simple modification to implement bookkeeping of inputs requested trough API (from quick look it seems only method to return inputs array is needed) would create a base for auto id calculation for view cache in application, dropping the need for manually listing those safe parameters in display method.

Regards,
Klas

2015-02-16 23:30 GMT+01:00 Andrew Eddie <mamboblue AT gmail.com>:
My 2c worth.

## Consolidated Code Repository

I personally don't think this is optimum. While, sure, it makes checking out the Framework easy, it does complicate matters. 

It doesn't promote isolation of the code (we've had cases where tests passed in the full stack, but didn't on an individual package because some test scaffolding bled into other tests). 

It makes the tests for each package longer to run (if I want to make a quick fix to Keychain, I have to wait for all the other tests to run first).

It doesn't allow for incremental changes to individual packages to happen when they are needed (for example, many packages could go 2.0 right now, but it's not happening because some packages are not quite ready). 

My personal preference, and it's come from working in both the Composer and NPM universes, is that individual package are the point of truth, manage their own dependencies (the less the better) and their own lifecycle (some packages will get a lot of support and change a lot, some won't - so be it).

In terms of being able to download the whole Framework, this can be done with Composer's create-project feature. In fact, you don't want to do that at all. You want to spin up a half-dozen examples of starter applications (command line, REST, web site, et al) that people can pull down and have a skeleton application up-and-running very quickly.

## Documentation

Given the previous comment, I feel strongly that documentation should still live with each package.

However, the intention was always so be able to build the programmers API into one site (from the DocBlocks), and also compile all of the package documentation into one master site (something like what Laravel does would be what I would aim for).

The advantage of leaving the docs in the same repo as the code is that you only need one pull request to check that the documentation has been adjusted appropriately for any given code change. 

To put it another way, it's easy to automated collecting docs from several sources. It's not easy to automate checks that there is a PR for code (and tests), and a PR for docs. The split strategy has never, ever worked for the CMS, but having docs and code in one contributor PR has worked in the Framework for many years.

## Minimum Supported PHP Version

I think each package should be able to govern what it needs as a minimum version, and 5.4/5.5 should be allowed on merit.

## Package Specific Goals

### Cache

I've actually been thinking lately that a Cache is just a storage layer, and that this can be combined with the Database abstraction layer.

### Filesystem

I really question whether this is necessary any more. At it's heart, it's really just a storage adapter.

### Form

This needs a lot of work and split into several packages: data validation and HTML form building.

### Language

I'd love to see Language converted to an adapter pattern so the the API can use any sort of language file/storage format, not just the Joomla .ini definition. It would then be a good candidate for a PSR.

### Log

This is a bit of a cross-over comment, but I think it would be a good exercise to implement Monolog in the CMS, and build out a legacy JLog interface layer. 

To be honest, I think that strategy should be used more and more to replace all the old junk in the CMS.

... 

That will do for now :)

Regards,
Andrew Eddie

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.