Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

All other Modules /

Discuss all other Modules here.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Modules integrated into mysite...

Go to End

12 Posts   1856 Views


Forum Moderator, 1899 Posts

8 July 2010 at 12:02am


I regularly use a couple of modules in sites and I am obsessed with keeping everything within mysite or the theme dir. This makes it easy to store in SVN and always find relevant code. To take a module like... multiselectfield... I could just place those files within the relevant mysite folders and I am done right?

I accept that updraging might be slightly harder... but that is mostly the point... I want to not worry about pulling different versions from different places.

I guess I am asking if this goes along with the terms and conditions... or maybe how others handle this sort of thing.



Forum Moderator, 5523 Posts

8 July 2010 at 6:34pm

Feel free to move the code. This of course will make it harder to upgrade and clutter your mysite folder but SS will pick it up if its in /module/ or /mysite/ only thing you'll also need to do is move config settings to your own config.


Forum Moderator, 1899 Posts

8 July 2010 at 8:52pm

Thank you Will.

I am only doing this with sifr and multiselectform right now...

in addition to moving the files (I have created sub folders in code/javascript/css for 'modules/<module name>') I needed to update the init function in the php to reference the new locations of the js and css.

Ahhhh much nicer and tidy now :)


Forum Moderator, 5523 Posts

8 July 2010 at 10:14pm

There was a discussion about the folder structure in a quite old thread on the dev mailing list and I like the idea of having a modules/ folder (and a themes/ widgets/) but we decided against changing it in the current branches since it would break a few workflows (nested svn externals were another reason we avoided it).

Maybe in future releases it'll be revised globally so you won't need to worry!


Forum Moderator, 1899 Posts

8 July 2010 at 10:34pm

On the subject of folders... :)

In mysite code I have pages & model folders.

models => DataObjects
pages => Page objects

I tend not to place ANY functions within the dataobjects as I feel this should purely be MODEL (aside from getCMSfields and alike)
then in pages this is CONTROLLER only and I tend not to associate the data right there

then I figure the VIEW is in the themes / mysite/templates

then larger bits of controller code in other places outside of those folders grouped loosely around one or two data objects into a "manager class". But then this might be overkill for many sites, it seems the sites I have worked on have a fair sized data model.

It took me a while to coalesce on this and now find it helps to keep all my code MVC...


Forum Moderator, 4102 Posts

9 July 2010 at 1:35am

Not having any functions in your model is not necessarily adhering to MVC. To me it sounds pretty whacky, actually. Why would you want to do that? Your model should provide each record with the smarts it needs to behave in your application. Consider a model that has a function "FullName()" that concatenates the FirstName and LastName field.. or a Thumbnail() function that returns the attached image formatted according to the application's settings. Without member functions in your model, you're updating every single template that implements those methods when the requirements change. That should definitely not be in the view, and to put it in the controller means you can only use those functions on one template.

I agree that the model should never have a ton of logic in it, and its methods should be short an utilitarian...

function DownloadLink() {
return $this->ExternalLink ? $this->ExternalLink : $this->AttachedFile()->URL;

But to say no functions at all seems like a severe handicap to me.


Forum Moderator, 4102 Posts

9 July 2010 at 1:45am

@swaiba -- I have to respectfully disagree with you... I think one of the biggest limitations of the framework right now is that "mysite" just becomes a huge dumping ground for all kinds of disparate code. Smaller, bite-sized modules would really help keep things organized.

@Willr -- Two comments..

1) I read about the "Developer mailing list" yesterday in the docs, but the link took me to an empty wiki page. Do you have the info? I'm interested.

2) If I can share my thoughts on the folder structure, I like most of it as it is, and I don't think too much has to be changed. The only thing that bothers me right now is that sapphire is at the same level as cms, mysite, and all the other modules. I would like to see Silverstripe evolve into more of a framework-based solution, and emulate the design patterns seen in frameworks like Symfony or Zend. It would be great if the sapphire framework lived external to, or above, all of the working files that we use in module directories. I'd also like to see CMS treated like a module, since, in an ideal world, it's an independent application built on the Sapphire framework. I understand they're pretty tied together right now, but I'd like to see a day where there was a bit more autonomy between the two.

In general, a progression toward more modules and less of a catch-all mysite folder is a good one. If you've ever built a site with 50+ templates you'll see why. It's easy to organize the code folder, but templates can't have subdirectories, and it just gets nasty. I think it would be wise to think of individual page types, their models, controllers, templates, CSS/JS dependencies, as individual modules.

This is a good thread. I'm glad someone brought this up!


Forum Moderator, 1899 Posts

9 July 2010 at 2:06am

Hi UncleCheese!

I'll back up with a history here... I have a "product" site that is going to be installed in 20+ places and I have many versions locally... I do not want the entire web root (including SS) in SVN - just the mysite folder.
Also I am talking about only two core modules (at the moment ;-) - sifr and multiselectform... why keep installing them each time?

This is obviously not for all.

Regarding the MVC folder suggestion... You are talking sense... I overstated it just a touch with the "ANY"... There are some exceptions as you point out...

One of the worst things when using silverstripe for systems with complex data models is the lack of direct control of the database, this is of course in my opinion, and also paradoxically something I like and that has tons of benefit. I am much more used to have a script to create the database and manage updates - this is not possible here as all tables are under ss control... so best keep that part of the code model focused. And I find that about 3/4 table normally get managed by one piece of code, so the bulk of the controller code goes in there... then when needed it is only a couple of lines to use that bit on any specific controller or it is site wide... put it into Page.

I also have a couple of Abstract Pages that group functionality for other pages to inherit... like...

class SystemPage extends Page
	function getCMSFields()
		$fields = parent::getCMSFields();


		return $fields;

	function canEdit(){return false;}
	function canCreate(){return false;}
	function canDelete(){return false;}

..for whenever I don't want this page messed with in the CMS.

regarding "mysite" just becomes a huge dumping ground for all kinds of disparate code"

I'd prefer not to dump anything anywhere and especially not in the web root. It may be a flinch reaction to some of the terrible code I have seen so far in web development... how about having a "modules" folder inside mysite? best of both worlds?

Hey I am still learning - I've only bee at this for 6 months - I know you have much more experience :)


Go to Top