I come from the IBM Rational ClearCase world (UCM and all that..) and as I remember the concept on Composite Baselines i wonder if there is something out there that has the same purpose for DVCS.
I understand that Mercurial/Git are "Get All the Code Base or nothing". But could be something that could manage the tags/baselines for different repositories and be able to manage those as composite baselines.
systemX/release-1 = subsystemA-repo/release-20 + subsystemB-repo/release-18 + subsystemC-repo/release-2
This mechanism will abstract the was i can query baselines to systemX-releasex and get the appropriate tags from the dvcs repositories.
Any ideas.
git submodules, hg subrepos, etc.
Related
I am looking for advise on how to develop a web application in Symfony2 by starting from a EER diagram. I appreciate a step-by-step primer of what you think is a reasonable way to develop.
Also, is there anything I should pay attention to avoid later failure?
Please suggest any tool I may use.
UPDATE: Let me clarify. Say I have the EER diagram below. A question is: is there a tool to convert it into symfony entity classes, with correct annotations about relationships (1:N, or N:M)?
To clarify even more.
Say I have developed a EER diagram as above.
By Workbench Export, I may get the sql queries to create the corresponding mySQL tables; hence I may use Doctrine/Symfony2's app/console doctrine:mapping:import to get a schema I may use to generate my Entity classes.
However all that is not exactly what I am looking for, since I would like to avoid that piece of reverse engineering. So, question is: is there a way to export a EER diagram to the Entity classes directly, and to leave mySQL table creation as really the last step?
If that is not really possible by Workbench/Doctrine/Symfony, is out there a different combination of tools which let me do so? (Zend; Ruby on Rails, ...)
UPDATE, it seems that Skipper Skipper does what I am looking for. Unfortunately it is not free/opensource (indeed a little pricey). Skipper has a export to ORM tool, which creates Entity classes for Doctrine (or other ORMs) from a EER diagram. I need to check how it performs with respect to relationships and annotations.
You can start from your EER diagram to define which doctrine entities your application is going to need and the relationship between them ( Note : If the relationships are not easy to spot you might need a class diagram ). Then I would suggest to follow an MVC design pattern for which Symfony is clearly oriented :
Once you have your entities you have your models.
Take a moment to define which routes your application is going to use
The easiest way to deal with controllers is to assign a different controller for each route (unless you really have a lot of routes)
Finally write your views to render your models and logic to the users.
Hope this helps.
Ocramius did in Doctrine ORM Module (for Zend Framework) a tool to visualize Entities diagram. It really helps to visualize the diagram to configure your objects relations...
I liked it in Zend, and used it a lot ! so I really missed it when I started to learn Symfony... I decided to find a way to do the same... and I did ! (it uses the yuml.me API)
I shared the bundle :
https://packagist.org/packages/onurb/doctrine-yuml-bundle
Installation is very easy in only 3 steps... Try it :)
I created a really nice script to do this. It converts the EER Diagram to Doctrine 2 entities which are symfony friendly and it allows you to totally customize how its done.
The first step is to download this tool (https://github.com/mysql-workbench-schema-exporter/doctrine2-exporter). I just installed it via composer (follow instructions on the github)
Next have the .mwb file be in the same directory as the script I am going to propose you make.
Next I created a script like this to customize the settings of that program.
autodoctrine.sh
php vendor/bin/mysql-workbench-schema-export youreerdiagram.mwb ./entities << EOF
`#Export to Doctrine Annotation Format` 1
`#Would you like to change the setup configuration before exporting` y
`#Log to console` y
`#Log file` doctrineconvert.log
`#Filename [%entity%.%extension%]`
`#Indentation [4]`
`#Use tabs [no]`
`#Eol delimeter (win, unix) [win]`
`#Backup existing file [yes]`
`#Add generator info as comment [yes]`
`#Skip plural name checking [no]`
`#Use logged storage [no]`
`#Sort tables and views [yes]`
`#Export only table categorized []`
`#Enhance many to many detection [yes]`
`#Skip many to many tables [yes]`
`#Bundle namespace []`
`#Entity namespace []`
`#Repository namespace []`
`#Use automatic repository [yes]`
`#Skip column with relation [no]`
`#Related var name format [%name%%related%]`
`#Nullable attribute (auto, always) [auto]`
`#Generated value strategy (auto, identity, sequence, table, none) [auto]`
`#Default cascade (persist, remove, detach, merge, all, refresh, ) [no]`
`#Use annotation prefix [ORM\]`
`#Skip getter and setter [no]`
`#Generate entity serialization [yes]`
`#Generate extendable entity [no]` y
`#Quote identifier strategy (auto, always, none) [auto]`
`#Extends class []`
`#Property typehint [no]`
EOF
This will create the doctrine entities for you. My particular settings turn on extendable entities because that way you can run this command over and over without overwriting model specific code. You just put your code in the class that is extending the base class. This will create a discriminator column in the database that you will want to ignore but its worth it for the logical separation.
Next you simply run the /vendor/bin/doctrine orm:schema-tool:create console command like in the symfony tutorials to have it create the database from the doctrine files! Let me know if this was clear enough.
References:
http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/tools.html
I have separated the various layers (Class Library Projects) in my solution explorer like this:
I want to use PetaPoco micro-ORM and someone suggested me to add PetaPoco in the Repository layer. As suggested, I added PetaPoco to the Repository project and generated model from the database. Now the auto-generated POCOs reside in the Repository.
What I am not following is when I want to implement DDD, I want all the POCOs in the Model i.e, the Business Layer.
I added a WebForm for logging in the user in the WebUI layer. Now when DDD is to be used, do I need an interface in the Model? Where to write the Validate Login method?
I strongly suggest you (re-)read Eric Evans book on Domain Driven Design. Also you should watch mr. Evans's videos after the book. DDD IS NOT about repositories, databases, assemblies, or user login.
There is also the possibility that DDD is not actually what you are looking for. Seems like you are looking for a layered approach with the ui on top on some entities/app-services on top of some repos on top of the database. Depending on what you are building, this might actually be all you need.
If you want to use PetaPoco and if your "orm" generates "models" from the db, then it does not make a lot of sense to separate them in different projects. The fact that the models are generated by the orm ( and the fact that they might need to be re-generated in the future ) makes them quite coupled with the orm so moving them in a separate assembly buys you nothing.
To answer your ValidateLogin question, i would suggest moving all auth related code to an infrastructure layer that is orthogonal ( vertical ) to the other layers. App users don't necessarily need to be "entities". You might also get away with having an app-service in the model layer that handles auth, but i usually found auth to be an infrastructure concern rather than a business concern.
In the end i would suggest you get familiar with the pitfalls and strong points of such architecture and then decide if it is a good fit for what you are building. On the other hand you need to be aware that DDD is not cheap to build and (as mr Evand said) you are probably not going to get it right the first few times.
Can someone let me know the basic setup of Compound Templating.Is there some reference document provided by Tridion.
You can find all about Tridion's templating model in this documentation topic (login required):
http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_Tridion_2011_SPONE/concept_1C08142900B34C21AC8A86DE54C9EECC
There is a very good training available for it, please see:
http://www.sdl.com/services/education-certification/training-product/web-content-management/index-tab3.html
The Modular Templating & Dreamweaver and MS.NET Templating trainings are the one you are looking for.
Some common points to be remembered, off course very generic but still important.
In schema naming Use lower casing on element names and replace spaces by underscore(_).
Use Genric text with Editors Terms of the description text
To show constraints with particular schema fields one can think of Schema facets
Always create TBB with the purpose of re-usability.
In Dreamweaver templates always use RenderField instead of the ##Component.FieldName## syntax to ensure that the SiteEdit feature always works.
During linking don't forget to use “textonfail” attribute.
Make sure parameter names don’t clash with items.
You can resuse TBBs for different purpose with help of different parameter schemas.
Many more generic points could be keep in mind and always follow as Best Practices to avoid rework. I hope the community can extend the list.
I want to use RDF / triples in my Symfony2 project in order to organize things (in my case it is Tags).
I would see something like this :
ENTITY TAG <-------------- TAG_TAG --------------> ASSOCIATION_TYPE
^ |
|---------------------/
Fields :
TAG
ID
Tag (text)
Description (text/html)
TAG_TAG
ID
*TAG1
*TAG2
*ASSOCIATION_TYPE
ASSOCIATION_PARAM
Like this, I would be able :
To store triple associations
To set different association types. For example, PHP is a Programming_language ; stackoverflow.com is a website ; but the Earth turns around the Sun.
To set parameters (which permits to give more information inside associations)
We could consider setting a many-to-many relation between TAG_TAG and ASSOCIATION_TYPE. By doing this we could set several parameters.
So I have several questions :
Do you think it's a good way to store triples efficiently ?
Is there any RDF layer to extract existing RDF/triples databases and populate my own ?
Should I consider using some kind of tripleStore like Sesame and use it with Symfony ?
To answer your questions:
1) I'm not entirely sure what you're asking. If you're asking if that's a reasonable way to model your data, it's probably ok. But your diagram is not clear and you're a bit light on details. Best thing to do is just do something that works to start with. You can improve the modeling later without much of a hassle.
If you're asking about storage of triples, don't. See my response to #3.
2) There are many RDF libraries available, you have Jena & Sesame in Java, dotNetRdf for the .Net world, RDFLib in python, redland for C, etc.
3) Yes. Don't attempt to re-invent the wheel and build your own triple store. It's not an easy project and you won't do better than even the worst existing triple store on any reasonable time scale.
As Michael said - please don't build your own triple store! There are several solutions available in PHP:
ARC2 provides a triple store based on MySQL
The librdf extension provides a PHP wrapper for the standrad RDF C library
The Erfurt Library is an abstraction library for connecting with the open source Virtuoso Server triple store, but also has its own triple store based on Zend DB taht can be used with MySQL.
I'm working on using the Repository methodology in my App and I have a very fundamental question.
When I build my Model, I have a Data.dbml file and then I'm putting my Repositories in the same folder with it.... IE:
Data.dbml
IUserRepository.cs
UserRepository.cs
My question is simple. Is it better to build the folder structure like that above, or is it ok to simply put my Interface in with the UserRepository.cs?
Data.dbml
UserRepository.cs which contains both the interface and the class
Just looking for "best practices" here. Thanks in advance.
General best practice is to have one class or one interface per file.
Here's the more generic discussion, which I think applies to your case:
One class per file rule in .NET?
As a developer new to your project, I would appreciate knowing that IUserRepository exists--without having to fish through your UserRepository.cs file.
Do whatever makes sense to you.
Personally I find browsing solutions for anything painful so I have hot keyed Goto Definition/Implementation and Resharpers FindUsages Go to Type, Go to File so I never have to click anything.
Combining interfaces and classes in one file makes sense if the class or interfaces are small.
Also if your following the Liskov substitution principal / a dependency injection strategy and general good design practices you would rarely be interacting with actual implementations anyway. Repositories should almost never be referred to by their concrete implementation.