PHP Roundtrip

[fbernoldi]

Hi,

For the past several months, I've started working with 3rd party PHP Frameworks, more specifically, with https://github.com/phalcon/cphalcon. With the developer tools you can generate stubs to include with you Developer IDE of choice or to reverse it into bouml to use it with your application model.

So, I created a new project (Phalcon Project) and reverse it without issues; then I added it to my main application project as a library and used the references.

The problems started when a new version of the framework came out; without the PHP roundtrip I couldn't update the Phalcon Project with the stubs changes, so I deleted all and reverse it again, no problems there; but when I updated the library on the main project, all references to the Phalcon Project was lost since apparently they are made by ids instead of names.

I haven't updated again the Phalcon Project since; so far there was no significant changes on the APIs that stoped me from using it as is, but maybe in the future I will have to re-reverse and re-reference the main project.

The questions here are:

First, is it hard to add this feature or plugout to bouml? maybe it isn't part of the software because nobody requested it in the past and it's quite simple to add.

And second, if not the case, can I develop this with my knowledge of basic c/c++ programming from collage? maybe copying and pasting from other plugouts.

Thanks,
Federico.

[Bruno Pagès]

Hi,

First, is it hard to add this feature or plugout to bouml? maybe it isn't part of the software because nobody requested it in the past and it's quite simple to add.

Yes there is no roundtrip for PHP because nobody requested it, and I do not already added it because I am not very comfortable with the restriction non-class classes non-class, for instance in your project phalcon the file ViewEnginesVoltTest.php defines two classes but only the first is managed because the second being after the function phalcon_prepare_virtual_path is not modeled, it is only in the artifact textual definition part

A roundrip is an extension of a reverse, it is more complex as the reverse, but I will consider to add the PHP roundtrip

And second, if not the case, can I develop this with my knowledge of basic c/c++ programming from collage? maybe copying and pasting from other plugouts.

If I am able to develop the roundtrip you can do it also, but it is simpler for me because even I made the existing reverses/roundtrip long time ago I still have their source code including the PHP reverse and you don't have (GPL version used an older release of Qt, I do not distribute the sources since years)

Regards,
Bruno

[fbernoldi]

Hi Bruno,

Thank you for taking the time to look at this.

Hi,
Yes there is no roundtrip for PHP because nobody requested it, and I do not already added it because I am not very comfortable with the restriction non-class classes non-class, for instance in your project phalcon the file ViewEnginesVoltTest.php defines two classes but only the first is managed because the second being after the function phalcon_prepare_virtual_path is not modeled, it is only in the artifact textual definition part

Yes I understand what you mean, I also don't like that kind of file structure, fortunately this are only part of the unit-tests; this specific framework is programmed in C as a PHP extension, so all the PHP code that gets reversed are stub files, empty classes and interfaces generated with a tool from the original framework's code. Those stub files respect the nice format of one class for file.

Of course if you were to add a reverse feature for PHP it would be expected to work with all kinds of files that where previously reversed with success.

If I am able to develop the roundtrip you can do it also, but it is simpler for me because even I made the existing reverses/roundtrip long time ago I still have their source code including the PHP reverse and you don't have (GPL version used an older release of Qt, I do not distribute the sources since years)

Thanks thats a lot confidence put on me, and I didn't thought about the difference on the Qt version, I thought about that since there were references on the http://www.bouml.fr/contrib.html about plugouts being contributed.

Federico.

[Bruno Pagès]

... Those stub files respect the nice format of one class for file.

The reverse works well when there are several classes into a file at the condition there is nothing between them

The C++ reverse discards the definitions between the classes, it is different in PHP because I consider the probability to have non class definitions is higher in PHP

Of course at least for PHP it is possible to process in other ways, supposing the source contain non-class-section-A then class B then non-class-section-C then class D :

• the non-class-section-C can be placed into the definition of the class A after ${comment}${final}${abstract}class ${name}${extends}${implements} {\n${members}}
• or the non-class-section-C can be placed into the definition of the class D before ${comment}${final}${abstract}class ${name}${extends}${implements} {\n${members}}
• or the non-class-section-C can be supported by a (pseudo) class, but in that case this pollutes the model with false classes

[fbernoldi]

... in PHP because I consider the probability to have non class definitions is higher in PHP

About this, in my opinion, modern PHP coding is tending to be more OOP than it used to be and also files to be more structured as well; in addition based on frameworks, i.e. you need a PHP app, you use Symphony, Zend Framework, CakePHP, Phalcon or another OOB Framework that tends to be cleaner on this aspects.

Of course at least for PHP it is possible to process in other ways, supposing the source contain non-class-section-A then class B then non-class-section-C then class D :

• the non-class-section-C can be placed into the definition of the class A after ${comment}${final}${abstract}class ${name}${extends}${implements} {\n${members}}
• or the non-class-section-C can be placed into the definition of the class D before ${comment}${final}${abstract}class ${name}${extends}${implements} {\n${members}}
• or the non-class-section-C can be supported by a (pseudo) class, but in that case this pollutes the model with false classes

The decision about if it's added on B or C's artifact it completely arbitrary for an automated tool, it may only have sense for the code writer's, take this example:

Code: Select all

<?php

class Hello {
   pubic function __construct() {
      echo "hello";
   }
}

$h = new Hello();

class ByeBye {
   public function ___construct() {
      echo "byebye";
   }
}

$b = new ByeBye();


vs

Code: Select all

<?php

function sayHi() {
   echo "hello";
}

class Hello {
   pubic function __construct() {
      sayHi();
   }
}

$h = new Hello();

function sayBye() {
   echo "bye";
}

class ByeBye {
   public function ___construct() {
      sayBye();
   }
}

$b = new ByeBye();


Both codes are well structured and ordered in their own way but; whether you pick the first or second choice of the list it will make sense for one code but not for the other and vice versa.

For that my opinion is that it's the developer's responsibility to adapt and correct this situations as they see fit.

I would not be concerned about trying to make sense in this situations as for what would be expected to happen and more about what it's told/documented to be happened.

But that's my humble opinion

Regards,
Federico.

[Bruno Pagès]

Of course at least for PHP it is possible to process in other ways, supposing the source contain non-class-section-A then class B then non-class-section-C then class D :

• the non-class-section-C can be placed into the definition of the class A after ${comment}${final}${abstract}class ${name}${extends}${implements} {\n${members}}
• or the non-class-section-C can be placed into the definition of the class D before ${comment}${final}${abstract}class ${name}${extends}${implements} {\n${members}}
• or the non-class-section-C can be supported by a (pseudo) class, but in that case this pollutes the model with false classes

The decision about if it's added on B or C's artifact it completely arbitrary for an automated tool

In my ways all the classes are associated to the same artifact because there is only one file for all, it is just different ways for the reverse to work, for the 2 firsts deciding arbitrary in which class definition a non-class section is placed

After there is also an other solution adding a new kind of element, like classes can have "extra member" one can imagine to have "extra definition" in deployment view and to be able to ask artifact to also generate them, so reusing my example the artifact is associated to class B and extra-definition C and class D (supposing the non-class-section A is still directly placed by the reverse into the artifact definition like currently). This solution is the best and can be used for all the languages but it requests an evolution of bouml and plug-out API and code generators/reverses/roundtrips

[fbernoldi]

In my ways all the classes are associated to the same artifact because there is only one file for all, it is just different ways for the reverse to work, for the 2 firsts deciding arbitrary in which class definition a non-class section is placed

I see, I was imaging two different artifacts.

After there is also an other solution adding a new kind of element, like classes can have "extra member" one can imagine to have "extra definition" in deployment view and to be able to ask artifact to also generate them, so reusing my example the artifact is associated to class B and extra-definition C and class D (supposing the non-class-section A is still directly placed by the reverse into the artifact definition like currently). This solution is the best and can be used for all the languages but it requests an evolution of bouml and plug-out API

So in this solution you could add "extra sources" elements that would be inside the same deployment view, and you could add them as classes to an artifact in the artifact dialog i.e.?

If it requires an evolution of bouml and plug-out API maybe you can plan it for future releases for the current release I would be really happy with the "current" way, maybe for clarity specifying in the docs when this case presents, where the non-class section goes.

[Bruno Pagès]

So in this solution you could add "extra sources" elements that would be inside the same deployment view, and you could add them as classes to an artifact in the artifact dialog i.e.?

Exactly

P.S. sorry I edited my previous answer renaming "extra source" to "extra definition"

[Bruno Pagès]

Hello,

The release 7.1 is available adding the extra artifact definition, they allow to remove the limitation about the file content during the reverse, mandatory step before to do the roundtrip. Finaly these elements are the children of the artifact generating them rather than children of a deployment view, this introduce a new sub level into the artifacts but this is more clear

The documentation is also updated

[fbernoldi]

Hello,

I saw the update today on the debían repository, thank you so much! I'll give it a try at once

Regards,
Federico.