Atomic core and packages
Posted 15 August 2011 - 09:30 PM
If it has grown too large? Yes, it has, most of users do not know all classes and features it provides.
A core package is good. There are many projects like crawlers or daemons where I don't have any web or something, but I would use the CComponent and like.
PEAR is close to death. It has a complex configuration managed by console commands, and can't live without it due to its complexity. It has a rigid structure as well. Check it to avoid its problems please.
The packages subject is related to the namespaces discussion. Do you plan to separate packages to their own namespaces?
I don't belive a package should have a configuration. Packages are not modules, they are plug-ins that you extract to the source, declare in main.php and use its API in your code.
Posted 01 September 2011 - 06:22 PM
Agree - a module or component may require configuration, but a package would not.
A package should come with some sort of manifest though, as discussed - this probably shouldn't contain any functional configuration as such, though.
Posted 01 September 2011 - 07:32 PM
I may be missing something on the discussion about configuration, but my two cents:
I believe that every packaged item (extension, module, component etc) should provide its configuration (at least the default one) to be added by the package manager to the application's configuration file(s).
There could be hooks for package installation and uninstallation, too.
Using these hooks, the packaged item will be able to automatically install itself to the filesystem and to the database.
The package metadata (meta file) could have also the version(s) of the framework for wich it is compatible.
Posted 06 September 2011 - 08:28 AM
If the framework core itself is distributed as a package with a metadata file, like any other package, a package manager would be able to check/update the core itself, the same way any other package is checked/updated.
It would be useful if the package repository provides a compatibility matrix based on feedback from developers, and this should of course take version numbers into account - when package X defines a dependency, it should specify the version number of the dependent package Y it was tested with, but when that dependent package Y receives an upgrade, you don't know for certain if package X is forward compatible with those changes. The package manager can build a compatibility matrix by collecting this information from developers.
Another useful feature would be to provide a release-date in the package metadata - that way, you can put up a candidate release package, for example two weeks before it's official release date. It's a simple communication tool: the vendor has indicated that the release may be superseded by another RC within those two weeks - and the consumer understands that they're using a brand new release which has not yet been widely tested.
One last thought: let's have a web-based package manager interface. Of course, it needs to be accessible from the command-line, for automation purposes, but a web-interface could have a richer user interface - for example, it could collect and display information from the compatibility matrix, render a dependency graph, etc.
Posted 06 September 2011 - 08:37 AM
Might make a useful starting point?
Posted 14 September 2011 - 06:21 AM
- search repo,
- find the package,
- check and display dependencies,
- download package,
- install package
CLI mode or HTTP (GUI) mode?
Perhaps separate module like Gii?
Looks like pretty big thing, uff.
But may bring the framework to completely new level of interaction during development - big step ahead.
Thumb up that you decided to keep modules - they are very powerful and useful.
Posted 10 October 2011 - 03:29 AM
I've a question regarding cli vs. GUI.
As far as I can tell there's currently no other way to run console command from within a web application than exec?!
Do you plan to add a component which works as a link between web app and cli app?
I played around with exec, but the problem is, that you often have different values for yiic on different systems (Win, Mac, Linux).
Posted 14 October 2011 - 08:22 PM
At the moment, Yii flexibility allows to create anything and plug it into the system by just set its alias/pàth and import them automatically when required. Any ideas on how those packages should be coded?
This could be a great feature, but nobody has talked about its format... ideas to work with package manager?
By following a pattern we could ensure the creation of top quality extensions... dont you agree?
Posted 15 October 2011 - 05:17 PM
cause it is scary sometimes to use others extensions cause you cant be sure they 100% correct without bugs ...
Yii Framework Demos
Common Yii Questions
Demo Blog Search with Zend_Lucene
Yii "registry" | Understanding the layout->view randering flow
Shrink Yii | Caching config/main.php | CPhpAuthManager - how it works, and when to use it
Theme Picker | Language Picker (i18n)
Posted 17 October 2011 - 04:52 AM
Moreover they should provide a default configuration, often the main application configuration is affected by an extension (such as setting params, loginUrl, etc.). This is another thing to think about ... can we simply merge any package configuration with the application configuration or do we have to implement boundaries?
Posted 17 October 2011 - 01:42 PM
Depends on what's inside the package. If it's a module then yes, most of your proposals are looking good but if it's a widget then there's no need to configure anything. I guess we'll just write a guide on extensions to encourage best practice.
Posted 02 November 2011 - 07:39 PM
I would avoid adding complication where it's not necessary, or at least make the default download contain everything.
Never forget the newbies. A seasoned Yii user can trim where necessary.
Posted 06 November 2011 - 02:08 PM
Going further with maven spirit building and installing packages into repository would be also great feature - putting common reusable extensions development into separate projects seems reasonable for large teams.
I also agree with db migrations support on package level. There should be possible adding optional information of migration objects existence, thus installing package can do necessary database schema modifications easily. I can even treat this as "must-have" feature.
Posted 08 November 2011 - 04:34 PM
I've checked these about two months ago. Did't like:
1. Lack of simple end user docs.
2. Symfony2 dependencies.
but now, as I can see, everything is in a PHAR and there are some docs. Will check/try it again. Thanks.
Posted 15 December 2011 - 02:08 AM
maybe it is a bit stupid because i do not know many examples you mentioned.. but could the Wordpress plugin system be somehow interesting as a reference?
the idea is that you can download a plugin from the Wordpress site, from the author site or install it directly from Wp admin area + eventually configure it (plugin developers can add an admin page to configure the plugin).