2.0.0 Extension Model/Standard

[craigh]

This ticket is meant to encourage a discussion and (eventual) finalization of a model/standard/prototype/pattern for Core 2.0.0 Extension Bundles.

current 1.4.0 standard is documented here

Core 2.0.0 will 'evolve' this standard but is not required to maintain Backward Compatibility.

Easy agreement on the following:

• Extends \Zikula\Core\AbstractBundle which extends \Symfony\Component\HttpKernel\Bundle\Bundle
  • This implies certain Bundle functionality as a Symfony Bundle.
• PSR-4 required (PSR-0 is deprecated)
  • requires a composer.json file (1.4 Module Standard & 1.4 Theme Standard)

[craigh]

Current questions in my mind:

Version

• I think we can move this data to the composer.json file
  • how/where?
• HookBundle Setup might be moved to Service Container tags with a compiler pass to gather them.

Installer

• Create an Interface instead of an Abstract class.

<?php
interface InstallerInterface
{
    public function setBundle(Bundle $bundle);
    public function install();
    public function upgrade($oldVersion);
    public function remove();
}

• Most Installer implementations will also implement the ContainerAwareInterface, although, the container can currently be extracted from the Bundle also. Discussion here, I suppose on best way to handle this. (The bundle does not include the container until post-install)

Bundle class

• could expand this to directly set Installer class and extract Version info from composer file

Hooks

• I'm wondering if it is possible to use Service Container Tags (see above) for all hooks instead of persisting them.

AdminInterface

• Purpose: implement admin Interface or Abstract #2112
• Idea: AdminAuthInterface / AdminAuthListener
• UPDATE: AdminResponse

Zikula\Core\Api\AbstractApi

• Needed? reconsider AbstractApi (and getLinks) #2494
• temporarily implemented in Core, but maybe isn't needed
• a current solution for the getLinks() method and providing other services (like translation) to the Api
  • maybe getLinks could be accomplished with an event.
• Translation could be moved to a Trait

[cmfcmf]

Regarding the

AdminAuthInterface / AdminAuthListener

This is something cool for 1.4, but will most definitely be replaced by "a proper thing" in 2.0:
http://symfony.com/doc/current/book/security.html#securing-controllers-and-other-code

/**
 * @Security("has_role('ROLE_ADMIN')")
 */

This cannot be done in 1.4, because Symfony Users and Security models are not yet adopted.

[craigh]

but will most definitely be replaced by "a proper thing" in 2.0:

One of the 'highlights' of Zikula over the years has been the security and permissions system. I'm sure Symfony is awesome, but we should consider how we might leverage what we have in addition to symfony's features. We don't have to always replace, replace, replace. If we do that, then we can just eliminate zikula and use symfony 😄 Anyway - I just think it is a discussion worth expansion.

@Guite - maybe we can add some time on the agenda at the camp to discuss this ticket and related topics.

[Guite]

added to list of topics on last keynote slide ;-)

[craigh]

For "fun" I've created a few code demos. see:

https://github.com/zikula/core/compare/FC-features

and

https://github.com/zikula-modules/Pages/compare/FC-features

and

https://github.com/craigh/BreakIt/compare/FC-features

updated 19 June

[Kaik]

Hi, quick one so permissions system and users. Same as @craigh I think our perms system is what defines Zikula and make it special. We may want to review it make it more user friendly. I have read sf docs about auth some time ago and I do not know if this is replaceable with our perms system I think it work in different layers/scopes you know more about that than me... Users I do not know yet how sf users works but I think anything will be better than our current profile/users module.

[cmfcmf]

I really didn't intend to say: "Remove all the Zikula stuff and replace it by Symfony". What I really meant was: "Review all the cool and good working Zikula stuff and see if we can build bridges to the Symfony counterparts".

[craigh]

Version Capabilities

in composer.json

• string keys
  • searchable
  • hook_subscriber
  • hook_provider
  • admin
  • user

values for each are arrays, but I think these can be standardized and made more useful. for example:

  "capabilities": {
    "hook_subscriber": {"class": "Zikula\\FooModule\\Hooks\\Definition"},
    "searchable": {"class": "Zikula\\FooModule\\Helper\\SearchHelper"},
    "admin": {"route": "zikulafoomodule_admin_index"}
  }

[cmfcmf]

There also is the question where to place these new classes and interfaces:

• in new Bundles (Zikula\Core\Bundle\Bar)
• in new Components, like Symfony does (Zikula\Component\Foo)
• directly under Zikula\Core

[cmfcmf]

When moving the Hooks from the version class into the composer.json file, #236 should also be considered.

[cmfcmf]

Also #249 (Module dependencies with an or) might be taken into account - although I think we could also close that one.

[cmfcmf]

#411 (Category Entity Support) and #418 (Plugin dependency) should also be considered.

[cmfcmf]

Also see #1286 (drak's 'What Modules can do')

[craigh]

I've created a SpecModule to enable further discussion

https://github.com/zikula/SpecModule

[Guite]

Closed as completed in the 1.4 FC layer. Feel free to reopen if you disagree.