eZ Community » Forums » Discussions » Developer preview of the new eZ...
expandshrink

Friday 14 October 2011 4:45:19 pm - 19 replies

» Read full blog post

Introduction

Today eZ unveiled the new public API concept at the eZ Day in Paris, for further development with our Community. It is a major step towards a layered architecture that allows easy functional extensions of eZ Publish.

Friday 14 October 2011 6:55:58 pm

Some samples code can be found at https://github.com/ezsystems/ezp-next/tree/master/ezp/Stubs/

Friday 14 October 2011 8:32:15 pm

So, it means that some of my latest blog posts are outdated, as long now we have this API.

I'm really, really surprised with this API, it is exactly what I was looking for ( actually I was using the kernel wrapper presents in the tests folder at github ), I really recommends everyone to check specially the link by Yannick: https://github.com/ezsystems/ezp-next/tree/master/ezp/Stubs (actually it answered all my questions, thanks!).

Now ez is becoming easier! It seems not to be a big deal at first, but it will helps a lot of extension developers as I can see. Combined with the latest tutorial about mobile development I think ez is ending the year with so much style,

Modified on Friday 14 October 2011 8:40:14 pm by Thiago Campos Viana

Friday 14 October 2011 9:13:23 pm

I'm not sure if the stubs are really up to date but they allow to get the whole idea happy.gif Emoticon

As I'm currently working on integration tests to ensure that the new API creates valid objects, I've wrote some scripts to do simple tasks like creating a content class (a Type in the new vocabulary) or publishing a folder content object (Content in the new vocabulary). They are not fully working at the moment but we are close to be able to publish a simple folder blunk.gif Emoticon

Cheers

Friday 14 October 2011 9:30:35 pm

Fantastic! Thank you for all this excellent information about the new API.

I can't wait to get started using it in my own work.

 

Cheers,

Heath

Friday 14 October 2011 9:53:32 pm

Oh I forgot to mention that some of the 1474 unit might also give some useful info happy.gif Emoticon

Saturday 15 October 2011 2:55:03 am

Congrats everybody!

A couple of questions:

  • I see there is a concept of notification events, but only pre_publish and post_publish seem to be hooked in, and even then I'm not sure they will trigger the existing eZP workflows. Is this correct? Imho content manipulation done via the new api should support all existing ezp triggers (including the ones that were not activated by default)
  • what about db transactions? there seems again to be only one added around the publish operation, and it is commented out...

Saturday 15 October 2011 3:23:44 am

The new API looks nice. We have been using the API of sqliiimport extension to manipulate the content repository before, but it's great to have the official user-friendly API like this, because we don't have to worry about the compatibility issues for future releases. 

Just took a quick look at the stubs, the code examples are quite straight forward, however, I just have a few feedback as following:

1. For ContentCreate.php, can we have an example / dump of the $_POST variable as the comment of the code base? I'm a bit confused about the following code snippet

// Another syntax could be valid, from post data.
// the post data follows same convention as structure of potential json import
$content->fromHash( $_POST['content'] );
// Or in case of unique id on existing content: $content->fromHash( $_POST['content']['id'] );

 

2. For package import, the "backslash" style is a bit inconvenient and unnatural, is it possible to change the "backslash" to ".", just like Java? Or support both of them?

A few years ago, we used a php framework called "studs", which is a php clone of "java struts" framework. From today's point of view, that framework didn't become very popular, but I really like its "." based package import syntax happy.gif Emoticon

Current style:

 use ezp\Content\Concrete as Content,
    ezp\Base\ServiceContainer,
        ezp\Base\Configuration;

Possibly new style?

 use ezp.Content.Concrete as Content,
    ezp.Base.ServiceContainer,
        ezp.Base.Configuration;

Modified on Saturday 15 October 2011 3:26:09 am by Michael Lee

Saturday 15 October 2011 3:31:07 am

@Michael: backslash is ugly if you're not used to it, but it is the namespace separator char in php. It is not an invention of eZP. We could probably use ezp.content.concrete, but would be from the language pov a single namespace, while it is currently 3 nested ones

Saturday 15 October 2011 3:54:25 am

Hi Gaetano,

Thanks a lot for your quick response. I think you are right, I just reviewed the source code of studs framework again and found its package import is as following:

import('horizon.lang.Object');
import('horizon.lang.RootException');
import('horizon.lang.Clazz');
import('horizon.lang.String');
...

It's actually using an import() function, not the php namespace, to simulate the java syntax and I thought ezc was using the same solution before. So looks like we will have to get used to the "backslash" from now on and hopefully php will change in the future.

Kind regards,

Michael

Saturday 15 October 2011 9:54:18 am

Hi everyone !

Thanks for this nice feedback happy.gif Emoticon.

@Gaetano: Workflows have not been worked yet. pre_publish and post_publish events are here currently for field types "onContentPublish" actions (see XMLText field type for instance). Also, there will be a proper support for transaction, but it's not exposed yet either (those methods are not implement atm).

@Michael: Yes, Gaetano is right, backslashes are the PHP namespaces separators, we didn't invent anything here blunk.gif Emoticon
About the fromHash() example, it was just an idea... As we said yesterday at eZDay in Paris,  HTTP layer is to be implemented also. Maybe this part should be removed from the stub.

Saturday 15 October 2011 10:39:26 am

@Michael Lee Please, you ca find informations about the syntaxe at http://php.net/namespace

Saturday 15 October 2011 11:52:24 am

> "So looks like we will have to get used to the "backslash" from now on and hopefully php will change in the future."

That will never happen, this is how namespaces look like in php, just get used to it, it is just a matter of habits. Long story short: They initially planned to use ::, but after the patch went into PHP 5.3 they found issues with that leading up to this rfc

> import('something.something')

We will never addopt something like this, that would introduce runtime overhead, while namespaces is handled at parse time and cached in eg. APC. 

Modified on Saturday 15 October 2011 11:52:56 am by André R

Sunday 16 October 2011 4:42:28 pm

@JV - can some more doc be added then to let implementors understand what is going on and avoid getting burnt by using things that are subject to change or incomplete?

- list of missing features. Wild guess: transactions, ezp workflows, information collectors. Anything more?

- methods in to-be-refactored state: use a custom javadoc tag for them if you cannot mark them protected

Monday 17 October 2011 10:57:09 am

@JV - can some more doc be added then to let implementors understand what is going on and avoid getting burnt by using things that are subject to change or incomplete?

And it would be great to have some background on the reasons (business/technical cases) for the new API, and be absolutely clear about how this will affect extensions, upgrades etc, how long the old API will be kept for... so that we can plan ahead, inform clients about implications etc.

Wednesday 19 October 2011 3:50:46 pm

 

And it would be great to have some background on the reasons (business/technical cases) for the new API, and be absolutely clear about how this will affect extensions, upgrades etc, how long the old API will be kept for... so that we can plan ahead, inform clients about implications etc.

Hi Geoff,

Good points.

Concerning the business reasons, i encourage reading the 3 first paragraphs of Christof's initial post. Additionally, we wanted to make it easier to learn eZ Publish. This is a major motivation. This will lead to a faster expansion of our Community, bringing more people aboard, pushing eZ Publish faster & further ahead. 

Concerning the status : it is a developer preview, the aim of which is to prime and sustain collaboration with the eZ Community on further developing it. It is not ready for large-scale business usage yet. It will start being supported in 4.7 (Etna) in May 2012, and foreseen as finished in the next one.

Concerning preservation of the old API : i will make sure you get an answer.

Cheers,

Wednesday 19 October 2011 3:52:02 pm

@All : let us use the dedicated forums for further discussing any PHP API related topic : http://share.ez.no/forums/new-php-api

Cheers,

Friday 21 October 2011 12:53:43 pm

@ALL: FYI engineering is busy certifying Annapurna this and next week. If that goes according to plan most of the team will return to focus on API from different angels somewhat after that, including pushing more documentation and tutorials so stay tuned happy.gif Emoticon

Modified on Friday 21 October 2011 12:54:23 pm by André R

Monday 19 December 2011 10:03:01 am

The reply has been removed because of violation of forum rules.

Monday 09 January 2012 6:06:50 pm

Concerning the status : it is a developer preview, the aim of which is to prime and sustain collaboration with the eZ Community on further developing it. It is not ready for large-scale business usage yet. It will start being supported in 4.7 (Etna) in May 2012, and foreseen as finished in the next one.

This is an important point and should be noted in the release notes I feel. That the API is not support in eZ Subscription till v4.7

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu