Alf’s blog about geek stuffs

Following my last post about authentication, I’ve implemented it in Wisss. I’ve also added a simple ACL management which retrieves all resources, roles and privileges from database and constructs a Zend_Acl object in the boostrap. I’m not very happy to have to retrieve all stuffs about ACL each time, but for now, I have no time to implement something smarter.

To manage ACL, I’ve also begun to generate an admin interface which is also for now quite simple (displaying a big table with all roles and resources). Concerning resources, I’ve define three layers : module, screen, action. I don’t know yet what is the best practice to apply ACL to a particular object. I will think of it during next weeks.

I’ve also added a block view helper which displays blocks in the layout if you are allowed to. A block is just a screen rendered as a menu, what minimize concepts in the model. There’s also a special block : the context. Thanks to a context action helper, each action can register contextual action which will then appear in the context menu. For instance, the “create” action will be able to set “edit” and “delete” action as contextual actions.

I’m busy this week, and I was this last two weeks (giving a ZF formation ) but I will switch form generation to Zend_Form as soon as possible. Despite my first opinion, which was against the use of Zend_Form, I find this component very useful and productive. Even if it’s bad to put view logic in the controller, it seems to be far easier to maintain.

I think the 0.3.0 release will happen soon including everything to build a blog example (and many other application). 0.4.0 will focus on cleaning up the code, polishing the interface, trying to improve ACL. I hope there won’t be a 0.5

Things are moving on in Wisss, I’ve been working on presentation and business logic over the last couple of weeks. It’s beginning to be presentable. This 0.2.0 milestone is not yet finished but already I can show you how it handles the model and what it generates.

Concerning the metamodel, I’ve defined two new packages: view and workflow. View metamodel allows you to define widgets by adding attributes from class data, references to classes or other widgets. The goal is to avoid generating CRUD forms by mapping to classes, which is not always exactly what we want. In the example, it allows you to create a new blog post with a new category. Another use case is to only show a part of a class.

The workflow metamodel, which may be soon renamed to dataflow (thanks to Tortoose for pointing this out) aims to define simple business processes. Like for views, generating simple CRUD processes is not enough for real projects. You often want a form which will create an object associated with another object or a wizard to dispatch creation in several actions. To achieve this, I’ve made a kind of dataflow to define simple algorithms. It allows you to link activities with each other using transitions and define what is for instance a blog post creation process. Activities can be either predefined or user defined. For instance, there is a Create activity which is related to a class. It takes several parameters in entry, mapped to the related class and returns an object.

For these predefined model entities, I’ve played with the code generated by JET. It’s the part which allows me to have a model editor from the ecore metamodel. For instance, what I’ve made is to add in and out parameters to a create activity when you choose its type.

I’ve made a flash demo of the model creation for a very small blog example (Icon set for new packages have not yet been done).

Concerning generation, I’ve added a configuration file for an apache virtualhost, a simple bootstrap, controllers, business objects and view templates. Each widget generates a template and IO activities (input or output) generate the templates which will be used with the controllers. I’ve used the new partial() function to achieve widget inclusion.

Concerning the work dataflow, I generate a business object for each process which contains a static method for each activity (which is not IO activity). A controller is also generated for each process and a controller action is added for each IO activity. A java service generates activity calls in the right order by browsing transitions.

I’ve also made a flash demo of the generation and the webapp working.

Concerning the next steps in Wisss, I may achieve the 0.2.0 in the next days, implementing all typical activities. The next 0.3.0 will add authentication and ACLs and the 0.4.0 will be the right time to add error management and user code blocks. I may find a 0.5.0 milestone before the 1.0 but I hope it will be the last. Now Wisss is presentable, I hope that the buzz will grow in the PHP community.

Thanks to Akrabat, TubularBell and norm2782 from #zftalk for proof reading.

While preparing the Wisss module for Acceleo 2.2 release, I’ve made a tiny icon set to replace default one and to show you a simple Wisss model :

I’ve seen that old demo videos have been clicked although the link is down. I will put them back in the next days.

It’s 6. a.m. I’ve not yet commited since the Acceleo’s SVN is down but I’ve achieved my first milestone : manage persistence. For now, Wisss allow to define a data model, similar to Merise and generate all DTO and DAO based upon Zend Framework.

I will enhance this feature in the future but it can already save dto in a mysql database. It manages 1-1, 1-n and n-n associations too. It allows you to save each object independently or in one step with a “sync” method. Loading is done by lazy loading and array of primitive type attributes are serialized to blob.

It avoids duplicate objects (and then save memory) by using a dto registry wich insure that there is only one instance of a same Business Object (or Dto, no distinction in Wisss for now) at a time.

Concerning the saving policy, I’ve put the focus on generating optimized queries. That’s why a change recorder observe each object for changes (sic!) and is then polled during saving process to only insert or update what is needed.

Finally, the “sync” method have to be preferred most of the time since it shortcuts the problem of browse a graph of objects. It browses the dto registry and save all new or modified objects. The save method will be useful for specific saving inside a transaction.

Bugs must remain but I’m very happy of what I’ve done, mainly in the last 2 days rush. I’m hopeful for the future, a future where I do not bother anymore about writing sql queries rather than concentrating on business logic. Simplicity like in Zope is possible, even in PHP !

See you later, I need to sleep and come back to my musician life for the week end.

I’ve got 2 months of work on Wisss from my boss \o/ I’ll start these days since I’m working on an other project but not full time.

The first steps will be to define a clear roadmap to achieve something at the end of these 2 months. I was thinking about defining the metamodel v1 and coding the generator for Data Access Object. We have a lot of work to avoid pitfalls encountered on the last project and find the good compromise between framework and generated persistence.

On the other hand, it would be great to have a full working generator, managing persistence, business logic and presentation. But I don’t want to make another “merely working” generator. I aim to have parts which do their job well. Focusing on persistence will allow contributors to already think to the other layers. Indeed, my reflection is more advanced on persistence since it is quite the only thing we have managed in our last project.

For now, I will fill the Trac wiki for contributors, available at http://trac.wisss.org, and start to communicate about the project.