Book a Demo

Author Topic: PHP5 Code generation - buggy ?  (Read 12825 times)

maYer

  • EA Novice
  • *
  • Posts: 11
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
PHP5 Code generation - buggy ?
« on: November 24, 2005, 08:57:46 am »
Iam coming fresh from Umbrello cause of refactoring reasons.

So the first step i did is, to import my current PHP5 classes. It worked well, but all attributes/members are now from type "var". Ok i thoght maybe EA cannot read the "PHPdoc" from Umbrello, where umbrollo saved the types.

Then i created 2 dump classes, on has an member of the second class. When i generate both classes, the syntax works well. But as i can see in the file, there is no "PHPdoc" for saying, which member is from which type, as you cannon declare it "syntax" wise.

So when i tryied to make a "syncronise with code", he updated my UML-Class-Diagramm an all members, espaciall ythe one, which was declared as "class1" is now var.

Did i missconfigurate something ? I switched genartion to PHP5 code, but still nothing changes. I mean, the whole reengeneer thing is fully useless, when this doesn work, as anytime the diagramm loses any value and you got to "reselect" nearly 1000 atribbs and asign them.

The second thing is, when i select a parameter datatype and then let the code generate i get a : myMyethod(mytype$myvar); this would accur to an error.

Has someone any tips, customized the generation ?

My version is 6.0

best regards

maYer
« Last Edit: November 25, 2005, 05:12:42 am by maYer »

maYer

  • EA Novice
  • *
  • Posts: 11
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Re: Problem generation PHP5 code
« Reply #1 on: November 25, 2005, 01:53:17 am »
It seems like its just a template problem.

I could fix several bugs like generating a constructur in interfaces or setting the type for parameters.

But i cannot believe, iam the only one, who has this problems. Are there any template ressources where all this is fixed?

Iam really disapointed of the product, as the PHP generation is more than poor..

But still there is the chance to change the generation by editing the templates, and thats great but also a lot of work.

best regards

maYer

thomaskilian

  • Guest
Re: Problem generation PHP5 code
« Reply #2 on: November 25, 2005, 03:50:43 am »
If you think the templates are wrong, send a bug report to Sparx. I also use PHP but only for my home brew web pages. There are several users with broader PHP experience than me. They'd probably be happy if you fixed a bug...

thomaskilian

  • Guest
Re: Problem generation PHP5 code (your mail)
« Reply #3 on: November 25, 2005, 04:16:06 am »
Hello E.(?),
I post here since I think it's of public interest. I hope you don't mind.

As stated I'm only a very small PHP user - and also PHP4 since I haven't upgraded my server jet.

Regarding the templates: there are none for PHP5 except those distibuted with the .EAP files. The registered user section contains MDG files for Phyton, but not PHP5. My suggestion to you: if you changed the templates, let Sparx know about it. Their support is very responsive (never seen anything comparable!).

You are right that the transformation for PHP is missing. But you can simply write your transformation (see here)

There are several PHP users, but not too many posts cover that topic, for whatever reason. It would be nice to have more users asking for PHP support (;D for my sake).

maYer

  • EA Novice
  • *
  • Posts: 11
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Re: Problem generation PHP5 code
« Reply #4 on: November 25, 2005, 05:07:34 am »
Surely you are right thom., but the thing is, we need this tool to develop PHP with reverse engeneering and we would PAY for it.

For the fact, that sparx write out some PHP reverse engeneering and its just BAD. There are bugs all over . Some can be fixed, also by me after reading the template specifications in the manual(Interfaces, prameters etc.). But the manuel do not cover it as much, as i would wish to. The second thing is, that the templates are not that "clever".

When you try to put in some additional, for example, notes for an attribut(for e.g. you put in the datatype for later sync. readout), you can handle this. The problem is, that when you do this, the whole code is generated after each sync. So the whole class declaration stand  3,4 times in the file ( as often es you sync), just because you added a "note". As there is NO transformation file for PHP, you cannot handle this "read out the datytype from the PHPdoc(its the same as JAVAdoc).

Here just would be the best and fastes way to ignore the "var" declaration for the UML-modell and just do not touch the datatypes declared there.

So here are problems over problems, and the reverse engeneering is not working in a case, that you can use it.

The idea of templates and the product is great, and its the ONLY one out of 20(out off all)  which "supports" PHP reverse engeneering.

In conclusion, iam a bit carefully now with the "features" standing in the list of EA. When some/most features are like the "PHP RE" support, iam not gonna even think about buy this product.

The sparx staff, let me estimate, needs 3-4 hours to implement a full working PHP reverse enegneer ( RE ) and would get,  many and i mean many, new customers as there is NO concurrence and a big "asking" after a tool like that, after PHP5 is more and more OO.

best regards

maYer
« Last Edit: November 25, 2005, 05:11:15 am by maYer »

thomaskilian

  • Guest
Re: PHP5 Code generation - buggy ?
« Reply #5 on: November 25, 2005, 11:55:52 am »
You're lilkely right in what you say. So we'll wait for a comment from Sparx on monday. Have a nice weekend.

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8110
  • Karma: +119/-20
    • View Profile
Re: PHP5 Code generation - buggy ?
« Reply #6 on: November 27, 2005, 01:44:35 pm »
Hello maYer,

What exactly are the errors that you're experiencing?  I see two template issues that are easily fixed.
  • Generation of parameter type hinting not including space between the type and the name.
  • Generating a constructor in interfaces.
I also see that you want a feature to have datatypes handled when the language doesn't handle them, and also possibly a transformation to PHP.

PHP5 support is included in the built in PHP templates, and no other templates are necessary.

We're sorry that you haven't had a good initial experience with EA, but I'm sure that if you stick with us we can resolve these issues.

maYer

  • EA Novice
  • *
  • Posts: 11
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Re: PHP5 Code generation - buggy ?
« Reply #7 on: November 27, 2005, 04:38:08 pm »
Hello, glad to have a developer by hand.

Simonm iam not tested it extensivly as the bug i describe below is so important, that iam not gonna test the system further, until its fixed.
Bugs i found and fixed :

- Do not create contructors/destructors for interfaces, if its selcted to create it for classes in dialogues

- php5 is not properly supprting type definitions of parameters, so better put that out


But the last and far more important is that one with datatypes. Yes your right, PHP5 itself is not supporting datatype definition, but when working with an UML-Model, thats essential. Also for example we are tryingt to develop with "inname Datatype" defintion and PHPdocs for defintion like :
Code: [Select]

class MainClass
{
 /*
 *@type : MyCustomClass
 */
 private $objFirstInstace

 /*
 * @type : MyContainerClass
 *\
 public $arrObjHolder
.
.
}



So there are several advantages as PHP5 is more and more OO oriantated. Iam not going to explaint what the advantages of dataype definitions are, thats clear to all. But they are essential for a UML-Model and thats what your Software stands for. Using it as an PHP-Editor is just not in the minds.

So what iam asking you to, is to inlcude a function, which generates that or some kind of PHPdocs for Attributes/Parameters and also reads them out on refactoring. The really important thing is, that the model has the highest priority, so if there is no PHPdoc like type for the member, the value setted in the Model should be kept, until it will be for example, manually overwritten by @type : var in the code. Of course you need that for parametes too, as they are also handeled by the Model.

When this happens, you have a really powerfull tool with templates and an all in one wonder. As your the only one which developed a php-reendgeneering as i know thinking of 25 commercial tools,   you should really do that step as fast as possible. I know, that many PHP5 deveoper are searching for such tools and they are defently willing to pay your price.

best regards

E.Mayer
« Last Edit: November 27, 2005, 04:41:57 pm by maYer »

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8110
  • Karma: +119/-20
    • View Profile
Re: PHP5 Code generation - buggy ?
« Reply #8 on: November 27, 2005, 07:29:01 pm »
Hello E,
  • Do not create contructors/destructors for interfaces, if its selcted to create it for classes in dialogues
    Done, this should be fixed in our next patch release.
  • php5 is not properly supprting type definitions of parameters, so better put that out
    I found a bug in the parameter template for this that meant no space was generated between the hint and the name.  This should be fixed for the next release.  Is this what you were talking about?  Hinting is in the spec.  See http://ch2.php.net/language.oop5.typehinting.
  • Supporting datatypes.
With datatypes we start having issues, the first of which you gave me in your post.

You defined the type of an attribute with a comment
Code: [Select]
/*
* @type : MyCustomClass
*/
Other examples that I have seen use
Code: [Select]
/*
* @var MyCustomClass
*/
for the same thing.

This lack of a standard is a big hurdle to what you want.  Even if we had implemented EA to look for @var, your types wouldn't have come in.  If we can resolve this then we may be able to add support for type handling for PHP.

If you wish to have types generated in the notes, you can modify the templates.  With just a few small template modifications you could make EA generate types into your notes, and then you can model complete with types in EA.

The only thing you won't be able to do is reverse engineer.  The current behaviour to override the type is because the reverse process is specifying a type (even if it is var) and in general when reverse engineering, the values specified in code should overwrite the values in the model.  (Otherwise it wouldn't be much use)

Now, we may (I can't promise anything) be able to make an exception to this for PHP.  However, another argument would be that once you have the model in EA, you shouldn't be reverse engineering it.  Instead you should be making your modifications in the model and generating them out.

maYer

  • EA Novice
  • *
  • Posts: 11
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Re: PHP5 Code generation - buggy ?
« Reply #9 on: November 28, 2005, 02:08:53 am »
Hello SimonN,


php5 is not properly supprting type definitions of parameters, so better put that out
I found a bug in the parameter template for this that meant no space was generated between the hint and the name.  This should be fixed for the next release.  Is this what you were talking about?  Hinting is in the spec.  See http://ch2.php.net/language.oop5.typehinting.

I didnt realized, that they really fixed type hinting in the last release. This feature was quite bug in earlier releases. So i deleted the parameter, instead of inserting a space. But i think this is great, as you did.

With the datatypes :

There is absolutely no standard for this, as it has been done manually by the developer in templates and there are NO RE tools. So i think, there should be no complaining, if you just decide to use on of these, and MAYBE can give an option. I think everyone is able to do a replace it in all files, if used another name.
The best solution is to make it configurable in the templates. Everyone is able to find tha "if == "@type" and change it as needed. When more and more people generating code with your app, the will keep that. And thats how standard made in common.
I think, there will be no one who set this standard until RE is widely used, so just keep that open.


If you wish to have types generated in the notes, you can modify the templates.  With just a few small template modifications you could make EA generate types into your notes, and then you can model complete with types in EA.

If i let generating the notes, he is somehow  repeating the hole class definition every sync. So its then 3/4 time in the file. I`ve studied the documentation, but for me, it was not that crystal clear, why this happens. I could fix the other two bugs, but i just cannot do this, sorry. Maybe you could help.


The only thing you won't be able to do is reverse engineer.  The current behaviour to override the type is because the reverse process is specifying a type (even if it is var) and in general when reverse engineering, the values specified in code should overwrite the values in the model.  (Otherwise it wouldn't be much use)


Lets devide this in two parts. If there is NO chance to include, that the PHPdoc defintion can be used for setting the type in the model, there should be just no changes be done on the model when synchronising. Cause if you sync, ANY datatypes are switched to "var". This makes the reverse-engeneering completely useless. Using your software just because of generating code, will not be in minds of people, which can get tools as Umbrello / ArgoUML for doing that, and they are for free.

So in conclusion, you just should take care of, that the datatype defintions of the model are NOT changed on sync, never or you include setting them by reading out PHPdoc. The last part would be a absolety highlight, the first part is absolutely essential for even use your programm for developing PHP-Applications.

After all that "complaining" i want to add, that iam not angry or trying to do some presure over to the developers. Iam glad that you even have support in the forum, which tryies to react on the wishes/discussions of the people. Thats just great and iam getting closer and closer to buy your product. The second thing is, that you just had a great, needed, idea with include RE for PHP, and its nearly done. But this last steps are absoletly essential that developer choose your software for PHP-developing. And there are a lot waiting...

Best regards

E.Mayer

« Last Edit: November 28, 2005, 02:14:35 am by maYer »

thomaskilian

  • Guest
Re: PHP5 Code generation - buggy ?
« Reply #10 on: November 28, 2005, 04:05:07 am »
Quote
... Instead you should be making your modifications in the model and generating them out.

To all those, not working that way: it's like Frankenstein's monster. Reverse engineering is nice for the first time, but afterwards it might kill you.

maYer

  • EA Novice
  • *
  • Posts: 11
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Re: PHP5 Code generation - buggy ?
« Reply #11 on: November 28, 2005, 02:16:04 pm »

Instead you should be making your modifications in the model and generating them out.


What should then reengeneering be for ? I mean did all things in the model, then starting to developing in the code, then adding a method, resync and tada, everything lost ? If i first have to add this method in the model, i can just forget reegeneering, cause when should i use it ?

I would like to have an answer, if sparx is gonna hanldle real soon, or we will start to search for other solutions.

Thank you

best regards

thomaskilian

  • Guest
Re: PHP5 Code generation - buggy ?
« Reply #12 on: November 29, 2005, 12:44:45 am »
Your code is always ONE presentation of the model behind. Similar to Plato's shadows, programmers tend to think of the code as reality albeit they are not the reality. If you try to trace from the shadow to the model behind (you), this is hard - very hard. You need to create pseudo tags in order to re-identify the meaning behind a shape. Instead, you should turn around and see the figures walking in the light behind you (aka the model). Try figuring out what it could mean to work with the "reality" instead of its shadow.

It would be nice to have better code editing integration inside EA. But you must not edit the code outside the model and then try to re-import.

Try searching this forum for the keyword "engineering" posted by "PaoloFCantoni" (omit the quotes). There are some very interesting threads.

mikewhit

  • EA User
  • **
  • Posts: 608
  • Karma: +0/-0
  • Accessing ....
    • View Profile
Re: PHP5 Code generation - buggy ?
« Reply #13 on: November 29, 2005, 01:00:34 am »
Quote
What should then reengeneering be for ?
Principally for importing legacy code into a new model ?
Quote
or we will start to search for other solutions
Attempted blackmail, or just impatience ? ;-)

But once you have the model, it should come first, no matter how "agile"::) your methodology.
Otherwise you're making patch wires to the circuit board without updating the circuit diagram.

maYer

  • EA Novice
  • *
  • Posts: 11
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Re: PHP5 Code generation - buggy ?
« Reply #14 on: November 29, 2005, 02:24:58 am »
Guys what are you talking about ?

If you develeopt a specific model, and afterward you start to write the code in teams, there are always changes to parametrs (mainly not of type, more the number), changes of adding small methods you didnt even think of while creating the model(if you would, iam surely you would call it overengeneered). If you got go into the model first, put the paramers in, then go into your code and write it down, then you just have MORE work.

Reengeneering is surely not for importing your code ONCE at the start and then just forget about it.


Iam not speaking of creating new classes in the code or something, that are things which have there dependcies and must put into the model first to see, which interfaces and methods it even needs. I think this is the point where your and my thinkings differ and why here are missunderstandings.  But the small changes in the classes themself are what iam speaking about. Syncronising with the model after each code step is worse, it`s stealing a lot of time.

And no, this is NOT a suggestion, this is what we are doing at the moment.

The fact is, having an absolute detailed and synchronised model is great for planing/maintaining or just upgrading.
Keeping it on that level without RE is just not effective and is steeling a lot of time.

best regards.

Mayer

« Last Edit: November 29, 2005, 02:29:53 am by maYer »