I am trying to code the process of creating Zend_Form objects using Doctrine2 ClassMetadatas so that form generation for my client database application is easier.
I needed somewhere to store the element labels, descriptions, and etc. using custom phpdoc tags seemed a good idea. But it seems ClassMetadataInfo doesn't provide 'annotations' outside what it's expecting.
Thats sensible I guess, but im struggling to find a way to get it to parse the entire phpdoc block.
I've looked at using getReflectionClass() and parsing it myself, but id loose out on the great caching. The Doctrine2 parser works really well for what it does, but I can't make heads or tails of it!
Being able to use the phpdoc short description as an element label, and long description as the description would be rather handy for my form<>model friendships.
Anyone else pondered on this?
Dotrine2 provides both an AnnotationDriver (which is used by the ORM) and an AnnotationReader (used by the driver and which provides more abstract method).
Take a look at the source
Doctrine\ORM\Mapping\Driver\AnnotationDriver
Doctrine\Common\Annotations\AnnotationReader
In case anyone finds this answer: The latest version of Doctrine as of now includes a more advanced annotation reader, including caching mechanisms (which you probably want). Take a look at the doctrine documentation for some nice examples of usage.
Related
As part of a professional project, I have need of a small parser for interpreting boolean-type inputs. I was able to use Antlr to create a working parser, and I was wondering if anybody here had experience and/or tips on integrating this parser, with the required Antlr libraries, into my Symfony2 application.
I have a class defining individual conditions (such as "attribute is greater than argument"), and I needed a way to combine these different conditions to create filters on the data within my application. The best way I found was to create another "container" class, referencing these conditions and having the information needed to combine them to produce the filter I need (basically a combination of DQL conditions). My problem stems from the client's request of being able to save and modify these filters, meaning I needed a simple way to keep them in database and recreate the whole filter.
Having these condition objects, I chose to use a Domain-Specific Language that I can use to save queries in the container (I dislike directly saving queries since they're difficult to modify afterwards IMO). I can save my filters in the container class in the form "((NOT condition1 AND condition2) OR (condition1 AND NOT condition2)) AND NOT condition3 OR condition4.
I have generated the associated parser, but now I need to integrate it in my Symfony project, meaning I need to integrate the Antlr library as well, and I don't really know how to proceed. I was thinking I could attempt to format the Antlr library as a Symfony Bundle, but I'm wondering what other ways there could be, and the comparative difficulties.
Does anybody have alternative approaches, as well as associated pros and cons?
What's the plus side of annotations for entity description in Doctrine2?
In Doctrine1 & Propel (which I've used many times), reverse-engineering a database to create yml or xml, then generating the model is a very quick workflow.
In Doctrine2, choosing annotations, one must write a large amount of boiler plate code just to get the entities in place..; yet annotations seem to be the 'way to go'.
What am I missing?
The workflow you describe from D1 and propel is exactly the opposite of the preferred way of thinking for Doctrine2. In fact, I avoided writing my own database definitions in D1 as well, for mostly the same reasons I give here:
In Doctrine 2, you are concerned first-and-foremost with your entities. Entities are just plain PHP object, and doctrine just handles your persistence. The fact that Doctrine is there behind the scenes squirreling data away in some database is an practically an afterthought. All of that mess is exactly what you're supposed to be abstracting away! In theory, you could get rid of doctrine at some future date, and write your own persistence logic. Your entities would still work just like they always have.
Looking at it that way, starting with a database schema is downright silly. You're more interested in your entities and the business logic embedded in and around them. That's tasty soup!
Now, since you're using doctrine for persistence of your entities, it (probably) makes sense to keep your mapping data right there with the class definitions.
So your new workflow is:
Design some entities by defining some plain-vanilla PHP classes.
Mark the class definitions up with some fancy comments for doctrine
to chew on.
./doctrine orm:schema:create and let doctrine worry about the
database table definitions.
Now, if you have some legacy database, things get trickier and a lot less fun. I've not really dealt with that scenario with D2, but I imagine it's ugly.
Regarding Boilerplate code: I see people complain about having to write getters/setters for their entities. I do something similar what this guy does - all my entities extend an AbstractEntity class which uses magic methods to generate getters/setters for any properties that don't have hand-crafted ones. Once you do that, there's practically no boiler-plate to be had.
Alternatively, there are plenty of tools these days that will stamp out the boilerplate for you (PHPStorm does this, plugins for Sublime, etc). This makes the boiler-plate fairly painless, and comes with the additional advantage that you can add type-hints, and your editor can provide useful auto-completion.
The main reason I use annotations over either yml or xml is ease of configuration. I don't have to look in another file to remember (for instance) what I set the join table name as in a ManyToMany relationship. And if I change something in a domain object (which happens a lot early in my development process), I don't have to remember to update another configuration file with the changes as well.
However, as you said, a database schema ports more easily to one of the other configuration formats, so in situations like this, you may indeed be better off using yml or xml instead of annotations. It all comes down to personal preference in the end... use whatever you're most comfortable with.
I'm working on a couple of CakePhp projects these days and I was wondering how I should document them. I'm used with ruby on rails where documenting is made easy with the help of the framework.
Is there anything like this in CakePhp? I'm looking at the documentation of the framework and I can't find anything about that. If it's not part of the framework, what would be the proper way to document my project?
You should try the Api Generator plugin (introduced here) used to power the official CakePHP API.
It uses the Reflection class (available in PHP 5.2 and above) to dynamically introspect your code's docblock comments meaning you don't have to regenerate your documentation for every change you make.
There are also a few extra features such as search indexing, calculating documentation coverage of your code, and allowing the use of Markdown in your docblock comments to generate HTML in your documentation.
You can always use generic solutions that apply to any PHP codebase instead, such as phpDocumentor or doxygen.
You will need to add docblocks to your code with the appropriate tags for any of these solutions to work (some IDEs can generate these for you). The core CakePHP code (and associated documentation) can be used as a good example of what is required.
A few subtle standards I have noticed the CakePHP team use when documenting code:
Never indent the docblock comment, even inside a class. This allows you to scroll through code scanning by docblock, and also allows you the full horizontal width of each line to type (usually around 100 characters).
Finish every sentence with a full stop (or period) as this acts as a good signal to let you know if each part of the documentation is complete and well thought out.
I am investigating Doctrine 2 for PHP and I am having trouble finding good resources for how to map using the PHPDriver. There is extensive documentation on using Annotations in comments for the Doctrine mappings, however, I would rather have my mapping definitions in PHP and NOT in comments (for obvious reasons).
I could use some examples mainly with association mapping. The documentation using Annotations doesn't really help me much. Using those I seem to be left guessing through trial and error on how to do it with the PHPDriver.
Does anyone know of a good reference off hand? Any help would be greatly appreciated.
If you haven't seen it already, there is a section on PHPDriver in the Doctrine manual now:
PHP Mapping
The manual gets updated quite frequently, so keep checking back for new topics. You may also want to consult the API documentation directly:
API Documentation
The general terminology and conventions used by all the mapping drivers are the same, so the basic ideas should translate. It's probably syntax that will trip you up.
I would also recommend you look into the XML driver as well. With a good IDE, you can get validation and auto-completion via the xsd file, which makes it easier. Writing out PHP mappings by hand personally strikes me as a bit labor intensive.
The PHP Drivers were rather low priority for now and until we add the programmatic builder that simplifies the PHP mapping it will probably keep being neglected vs annotations/xml/yaml.
However you will find a good example in the unittests (tests/Doctrine/Tests/ORM/Mapping) somehwere.
Can anyone recommend a good PHP paging class?
I have searched google, but have not seen anything that matches my requirements. Rather than "rolling my own" (and almost surely reinventing the wheel), I decided to check in here first.
First some background:
I am developing a website using Symfony 1.3.2 with Propel ORM on Ubuntu 9.10. I am currently using the Propel pager, which is OK, but I recently started using memcache to speed things up a little. At this point, the Propel pager is of little use, as it (AFAIK), only works with Propel objects.
What I need is a class th:t meets the following requirents
Has clean interface, with separation of concerns, so that the logic to retrieve records from the datasource (e.g. database) is encapsulated in a class (or at least a separate file).
Can work with arrays of objects
Provides pagination links, and only fetches the data required for the current page. Also, the pagination should 'split' the available page links if there are too many. For example, if there are potentially 1000 possible page links, the pages displayed should be something like FIRST 2,3 ....999 LAST
Can return the number of all the records in the table being queried, so that the following links are available FIRST, LAST (this requirement is actually already covered in the previous requirement - but I just wanted to re-emphasise it).
Can anyone recommend such a library, if they have used it succesfully in the past?
Alternatively, someobe may have 'hacked' (e.g. derived from) the current Propel pager, to get it to do the things I listed about - please let me know.
Not sure if this will fit the bill, but both sfPropelPager and sfDoctrinePager extend from the sfPager class, which provides forward/back motion and paging etc. You should be able to either use sfPager directly, or extend from it in the same way as Doctrine and Propel do with your array of elements to provide paging.
Typically, as this looks to be a "non-standard" use-case, there's zero docs on the Symfony site about it save for the API documentation, but the API docs look pretty comprehensive, and I'm sure the Doctrine/Propel examples will be able to guide you in the right direction!
I've been using and recommend the PEAR::Pager package which is able to do what you need.
You need to down into the sfPropelPager (or sfPager directly) code, understand how it works internally, where dynamic data is used and how you can get it working with memcache.
I don't know memecached but can't you cache propel records directly ? (I know they're huge :D)
My answer point by point :
1 : sfPager is DB agnostic as it is used by both sfDoctrinePager and sfPropelPager, you can use it for a working and tested base.
2 : sfPager should with work with arrays, the model class property referenced in it is not used anywhere. Cf source
3 : Providing pagination links is against separation of concerns, it paginates on objects and links are generated elsewhere (view file, helper, etc.).
You can display them as you want without modyfing the pager class or its descendents
4 : First and last access are provided by sfPager class
I know I can sound like symfony preacher, but this is the way we usually od things working with such a framework. As you wrote, do not reinvent the wheel !