Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Sarke

  • Rank
  1. Sorry about that, I will do in the future. Yeah, I've used some code analyzers and they don't like the size of my models either. I think Yii is more in the "fat models, thin controllers" camp, but it also has Behaviors and Events that attach to them. I will refactor it to use services (or something else), thank you for your advice. I do realize I can use the inline phpdoc blocks every time I use it, but I would much rather set this up once for each model so the IDE knows what the class really is. The issue is how Yii2 handles relations. In Yii1 the relations would always just return a the model or model[], so that was easily specified in the model's phpdoc with something like: /** * @property-read $author Author */ However, in Yii2 you can use either the relation results directly ($book->author) or get the query with $book->getAuthor(). The problem is this query, because it will be a generic ActiveQuery class, and it's one() will only specify that it returns an ActiveRecord, not an Author class. So, to accomplish this I create an accompanying AuthorQuery class using Yii's code generation module. Now the IDE knows that $book->getAuthor()->one() returns an Author model instead of a generic ActiveRecord.
  2. If you have a suggestion, let's hear it. If I extend the models I don't need to use the traits to store model-specific code. The latter is more of a workaround. That doesn't mean I am not using traits in other places. I am using Smarty views for all my HTML output. Or are you talking about view classes for each model, in which case would you elaborate? I don't see how model getters and such would be appropriate in a view.
  3. This is a post I made on the Yii forum, but it pertains to PHP in general as well. Any advice or insight would be appreciated. --- So, I have different aspects of the app: front-end ui module, output generation (pdf reports, etc), console commands and workers. Using the standard examples, let's say we have Book and Author models. These would all reside in /app/models/. Now, the issue is that there is tons of code that need to go into these models that relate only to the ui. There's tons that relate only to the output generation, etc. So to organise this I see a few options: 1. Put all the code in the common models. This is a bad idea IMO because it just creates a bunch of noise for when you are working on a specific aspect of the app. Much of the code does not relate to what you are doing. 2. Extend the models in each module. This seems like the obvious one. Have all the common relations and code in the common models, and then have child classes (app/modules/ui/models/Book extends app/models/Book) contain the specific code relating to to that module. The issue with this is that the relations will return the wrong class: app/modules/ui/models/Book would have a relation author that returns app/models/Author instead of app/modules/ui/models/Author Or, I have to re-implement all the relations in the child classes, and that's really not DRY. 3. Use traits This one seems wrong to me, but it does allow me to organise the code a bit. Basically, instead of using child classes that cause the aforementioned issues with relations, I would organise the "child class" code into traits instead, which would be used by the common models. So far I am leaning towards #3, but I really feel #2 is the correct solution but I don't know how to do that without repeating all the relations (and this app has a lot). One of the issues I have with Yii2 is the relation management. Each model will need it's own Query class for the IDE to properly be able to understand that it's a Book being returned by the Query, not an ActiveRecord. So far I've automated this, but having to add yet more Query classes would seem bloated. Thoughts? Advice?
  4. Thanks for your input. I will continue to use my style of choice. Weirdo...
  5. I like my braces style and I like my tabs. But I also realize there is benefit to using PSR-2 for more standard code when it comes to collaborating and contributing to open-source (some of which demand it). What compelling arguments can you make that I should switch to PSR-2 for all my PHP coding?
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.