Yes, there's a bunch of things to do to get it running. You don't really want to run this version, though, because I'll do a full upload again. Instead of shipping a full Symfony project, I'd like to ship the HLP/NebulaBundle/* part only, and add a small install script. I've also changed A LOT of things in the last 3 days.
On your local install, you should make sure that :
- you rename "app/config/parameters.yml.dist" to "app/config/parameters.yml"
- inside "app/config/parameters.yml" change these options to match your local mysql install:
database_host: 127.0.0.1
database_port: null
database_name: symfony
database_user: root
database_password: yourpassword
- from Symfony folder, run :
sudo chmod 777 -R app/cache
sudo chmod 777 -R app/logs
php app/console doctrine:database:create
php app/console doctrine:schema:update --force
If Symfony folder is at the root of your local web server, you can access pages from
http://localhost/Symfony/web/app_dev.php/nebula/ .
Register as a new user from
http://localhost/Symfony/web/app_dev.php/nebula/register/Once you are connected, the main pages (get started, mods, modders...) are empty, but you can access your own mod repository with a link on the right side of the nav bar.
(no theme on FoSUserBundle pages yet, sorry !)
I can't remember of anything else. If you used composer to get the deps, it should run.
If it doesn't, that means some yml config file didn't make it to github
If you want to start reading the code, you should know a few things :
- src/HLP/NebulaBundle holds most Nebula source code
- Resources/config/routing.yml lists all Nebula urls
- Resources/views contains the html.twig templates
- Controller contains the php controllers : they get variables from the router ({variable} in routing.yml), and return a response (generated html view, json response, redirection...)
- Request contains the ParamConverters. these classes handle variables from the route just before Controllers can use them. They make sure routing variables have a corresponding database entry.
- JSONBuilder is self explanatory
- Entity contains entities and repositories : every object specific to Nebula is in there. Repositories hold custom database queries.
- Forms are not actual forms, but php form builders : Symfony call these classes to build forms with my form templates.
- Security/Authorization/ModVoter is a class that makes sure you own the page. I call it directly from the templates to show "new/edit/buttons" buttons, and from the controllers before generating forms.
- Good to know : the method to create a new branch from scratch is actually in the *mod* controller. It's logical if you think about it
(same goes for every sub-object)
There are a few things I don't like in the current code :
- pagination, because it loads all entities from the database, and only display the right slice. I had to chose between efficient object preloading in the ParamConverter and efficient pagination. This is a limitation of Doctrine2 (the database abstraction layer above MySQL), but can be fixed by writing some complex native MySQL query. I'll do it at some point.
- ParamConverters sometimes preload too much stuff to avoid making more db queries (loading subobject lists when not needed). That's a small optimization, and not my current priority.
- The ModVoter only checks if you own the repository, and gives you the authorization to add objects. Templates use this "add" authorization even to show "delete" and "edit" buttons. I'll add a bit more granularity to this logic, and make the authorization name clearer.
@ngld : I'd like to take a look at the server side of the online converter. Could you send me the files ?