Sapphire / CMS Split

[Sam Minnée]

Hi everyone,

One of the things that we're planning for SilverStripe 3.0 is to have a clearer split between Sapphire and the CMS. We've given this a bit of thought internally, and I want to recommend an idea that may at first glance seem strange.

I think that we should include ModelAdmin and LeftAndMain in sapphire, not in CMS.

Why is this? I have a shallow reason and a deep reason.

- The shallow reason is SecurityAdmin. Without it, the permission system is non-configurable and of limited use. Pulling that out of Sapphire would leave Sapphire a little impotent. If we include SecurityAdmin, we need to include LeftAndMain.

- This raises a deeper issue. We are wanting to split of Sapphire, not for an abstract architectural purity, but so that it can be used to build applications that don't fit nicely into the 'managed content' paradigm. For myself, developing Dawn was such an application. I have also worked on other client applications that I can't get into detail about. In all of these cases, having a security management user interface, and having the ability to quickly create generic admin interfaces (with ModelAdmin) was very useful.

The end result will be that Sapphire gives you:

- An MVC/ORM framework
- A permission model, including a generic UI for editing permissions
- A quick way of making generic administrative interfaces

What do people think of this?

On a smaller note, I think that the File & AssetAdmin system is fairly heavily tied to the CMS, and so should be in the CMS module and not sapphire.

Thanks,
Sam

[Paul Bennett]

Hi Sam

+1

Coming from an MVC background, frameworks are great for building applications quickly but the effort needed to create admin screens to manage the application is always slower and more painful than it needs to be. It often feels a little like you're writing the app a second time just to get basic CRUD features and any other custom admin functionality.

(Yes, I know some frameworks had things like scaffolding, but these were always dev features and were completely unsuitable for production use.)

If Sapphire can offer the base MVC & ORM benefits as well as a configurable generic way to quickly create admin functionality (along with the required permission model) then I think it's a great move.

Paul

[Hamish Campbell]

Hey Sam,

Sounds like a good idea to me. That gives you a split between CMS and
framework that doesn't exist in other packages. That is, Sapphire
gives you all the basic developer tools you could want, while the CMS
adds the heavy UI/UX components for a world class user content
management experience.

Hamish

[Matt Bower]

+1

I mentioned giving Sapphire custody of LeftAndMain in the split a while back so I'm all for it.

For any purists out there, another idea is to make Sapphire a pure MVC/ORM framework with no UI/UX built-in for masochists who like to build everything custom and then have module you can add in that includes UI/UX components like LeftAndMain and ModelAdmin for generic interface starting points. I'd go for that too to appease said masochists.

Matt

> --
> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
> To post to this group, send email to silverst...@googlegroups.com.
> To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
>

[Sam Minnée]

I have no interest in appeasing masochists. That said, if there are as-yet-unidentified use-cases that we need to consider, now would be the time to raise them.

[Artyom]

+1 for all the reasons above...  Way to think out of the box : -)

[Dan Rye]

I'd say the module approach is a nice one.  Not so much for masochists, but simply for separation and giving the option.  It just seems cleaner cut to not include any UI/UX within core.  

That being said, I'm all fore leftandmain and security being separate from the CMS.

Honestly, I don't mind either way, just my 2 cents.

[Simon J Welsh]

In the current application I'm working on, we mainly use SecurityAdmin and ModelAdmin, with an occasional look with AssetAdmin (we need to be able to easily moderate user-uploaded images) and rather infrequently CMSMain to edit an error page, though that should be fairly easy to change to using ModalAdmin.

The most annoying part of the setup is that /admin is still CMSMain and (as far as I can tell) none of the other LeftAndMain subclasses can actually handle being the default admin interface, and parts of LeftAndMain break if you try.

With what you're suggesting, it would be nice if we could get AssetAdmin without needing the entire CMS module. Maybe decouple them enough that they're pretty much separate modules. Maybe imitate submodules? Something like cms/assetadmin/, cms/cmsmain/, cms/reportadmin/, etc so that we could just grab the folders, stick a _config.php in them and they'll work?

> --
> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
> To post to this group, send email to silverst...@googlegroups.com.
> To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
>

---
Simon Welsh
Admin of http://simon.geek.nz/

Who said Microsoft never created a bug-free program? The blue screen never, ever crashes!

http://www.thinkgeek.com/brain/gimme.cgi?wid=81d520e5e

[Marcus Nyeholt]

The purist in me says to separate the LeftAndMain and especially the SecurityAdmin stuff outside of Sapphire - the UI should just be a way of doing things that you can do in the underlying APIs of sapphire anyway. You should be able to specify the same permission sets via code as you can via the UI (well, you'd hope that the UI just interfaces to the same code APIs). 

The realist in me says that it's probably rare for someone to develop a Sapphire application and not want these parts as Sam has mentioned, and would rather make life easier for these 90%.

Cheers,

Marcus

[Sam Minnée]

I'm a little hesitant to fracture the codebase any further than breaking things into sapphire and cms at this stage, because

- the module manager is still a theoretical entity and I don't want to rely on it just yet
- i don't want to create another git repo; we already have too many!

However, I am thinking that it would be worth structuring our files such that the content of sapphire/core could be used as this stripped down framework, and potentially we have some kind of build process to create a Sapphire Core package from it.

[Dan Rye]

Best of both worlds Sam! That's my vote as well.

Sent from my iPhone

[Mirko Sassetti]

+1

Theoretically it would be better to make a complete separation, but in
practice is much better to have an admin interface, also in a
framework.
I say this based on my experience developing with CodeIgniter: it's a
good framework, but the problem come when developing the backend, so i
relied on other tools.

Mirko.

[Uncle Cheese]

-1

I'm clearly outnumbered here. :-)

If we boil this down, the driving reason for going forward with the
separation of Sapphire and CMS is a dogmatic one, isn't it? Sure,
debugging will be easier, and perhaps there will be some performance
gains, but really we're talking about principle, here, which is a good
thing. I love that SilverStripe always has the bigger picture in mind.

That said, a GUI for member management is not an essential element of
a framework. It's a modular and decorative addition to a framework. I
agree that member management itself is a key element of a framework,
but that doesn't mean it needs a GUI to support it. An ORM is a key
component of a framework, as well, but we're not talking about
bundling a database administration tool in Sapphire.

To bundle SecurityAdmin and LeftAndMain in Sapphire is opinionated and
bloated, in my opinion. My preference: leave the core components of
the Member, Group, Authenticator, etc. structure in Sapphire, and move
the GUI to the CMS. If you're developing an application purely in
Sapphire, you're probably apt to build your own SecurityAdmin, anyway.
In my experience, when my Sapphire projects rely on SecurityAdmin, I
generally make a number of concessions because it clearly isn't as
customized as the rest of my application, and it leaves my clients
scratching their heads. With that in mind, I don't think it would be
long before a community member developed a module for basic non-CMS
member management that we could use to get 90% of what we want and
build on it from there.

Sorry, I just can't stomach the idea of being force-fed the CMS
Security GUI when the separation of the framework and the application
is such a paramount concern of this release.

-UC

[Peter Bacon Darwin]

+1 to Uncle Cheese.  Just provide the Security Admin in its own module then people can choose to use it in their Sapphire projects as needed.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

---

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1435/3472 - Release Date: 02/27/11

[stojg]

Hi Sam,

I was actually thinking about this today. I wondered if I should
migrate a standalone application to only use the sapphire module for
the ORM.

My problem was that I still wanted to use the permission and role
system and wondered if which of these options I should use:
* Using 'Front-end' forms, that is, writing my own admin
* Extract the LeftAndMain, SecurityAdmin and necessary code to a
standalone drop in module.
* Include the cms module and to heck with all

I would like to have it as a standalone module, but I'm not really
sure on how much changes that will bring to the code.

I will probably just include the whole cms and might even hit my
deadline :)

[Sam Minnée]

Umm, no it isn't. In my original post I explained the pragmatic reason motivating the sapphire split, and hence why this was a pragmatic, not a dogmatic, choice.

[Sam Minnée]

Can we get some explanation of the kinds of projects that you would see yourself building that would make this split logical? I don't think a +1, -1 argument based on everyone's gut feel is the best way forward.

For those of you arguing for a leaner core, what about the whole form system? It certainly defines a lot of UI, does that need a separate module too? I only ask this rhetorically, because to remove the form system would whittle Sapphire down to pointlessness. We're still want to have a system that is a good choice for application development.

The really-lean framework - no forms, email handling, rest API, security, or UI - would be used only in exceptional cases; if you want that you can get sapphire/core

Remember, people: this is a pragmatic and not an ideological debate. We need to be putting *use-cases* on the table!

[Jamie Neil]

Personally I would prefer so see things follow a similar approach to
Django: keep the core as simple as possible and use modules to add
required functionality. So rather than moving the GUI functionality
into sapphire, separate it into an admin module which provides a basic
skeleton to support other GUI modules like the CMS.

Jamie

[Sam Minnée]

Actually, Django was an inspiration for moving The admin to sapphire - Django ships with an aim tool as part of it, doesn't it?

One thing to note is that once we get a reliable package manager working, we might fracture the codebase further. The question of 'what is sapphire' is more a case of

- what would be included in a standard .tar.gz
- what would be talked about in 'sapphire documentation

Compare this to jQuery UI: you can download a package that has only the controls you need, but the complete set of them is still known as 'jQuery UI'

[Jamie Neil]

I haven't actually used Django in a couple of years, and it's possible
I am confusing myself with Catalyst, but I seem to recall that
although it is normal to use the Django admin it was a module that you
had to install separately.

I think my worry about moving GUI functionality into Sapphire might be
a result of trying to customise LeftAndMain in the past and becoming
frustrated with it. If it was easier to extend and skin as required
then it would be less of a problem.

[Jamie Neil]

Yes, django.contrib.admin is shipped as part of the standard bundle,
but it's not activated by default.

[Sam Minnée]

Ye, this is definitely something we're working on, mostly in moving the frontend code to jQuery.

[Uncle Cheese]

From my point of view, we are talking about principle, here, because
building applications with Sapphire is already possible. It's just not
the cleanest thing in the world. As a real world example, look at what
I've done on http://www.xetic.org, a European microlending site. The
entire application is built on Sapphire, with a very small amount of
CMS -- so small that I could probably code it into obsoleteness in a
matter of hours.

They have nearly 500 "members" on the site as part of their lender
network. These are members in the sense that they live on the Member
table (heavily decorated), but they don't have access to the admin.
When the site administrators want to manage a given member, they're in
the SecurityAdmin messing around with a popup window with 10 tabs to
manage all the data associated with a member -- loan history, amount
loaned, friends, messages, etc. It's nuts. It just doesn't make a
whole lot of sense to be managing this sort of data in the same place
that you create a new account for the CMS, which only requires 3
fields.

True, if Sapphire shipped with SecurityAdmin, it really doesn't
preclude me from creating my own admin for a site like this, so who
cares, right? I guess I just feel like, if I'm at the point where I'm
creating my own admin interfaces for everything, why include all that
extra bloat?

I think as a starting point, I would say we should aim to keep a
framework invisible. You shouldn't be able to tell your colleague what
Sapphire looks like, or what Symfony looks like. The UI stuff is all
neatly tucked away in plugins and modules.

@Sam:

"The really-lean framework - no forms, email handling, rest API,
security, or UI - would be used only in exceptional cases; if you want
that you can get sapphire/core"

You may have misunderstood me... I certainly don't want a framework
that lean. The only thing I see in that list that I personally don't
believe belongs in a framework is UI. For the record, I'm completely
in favor of including all of the rest, including security -- just not
in a visual sense. As for forms, I think it's great to keep them, as
long as you don't bundle a stylesheet for them. :-)

On Feb 28, 3:39 pm, Sam Minnée <s...@silverstripe.com> wrote:
> Ye, this is definitely something we're working on, mostly in moving the frontend code to jQuery.
>

[Sam Minnée]

On 1/03/2011, at 10:01 AM, Uncle Cheese wrote:

> From my point of view, we are talking about principle, here, because
> building applications with Sapphire is already possible. It's just not
> the cleanest thing in the world.

The dozens of unnecessary tables that are created are a little more than principle.

> It just doesn't make a
> whole lot of sense to be managing this sort of data in the same place
> that you create a new account for the CMS, which only requires 3
> fields.

However, I'd say that a simple UI for creating and re-setting people's passwords is a sufficiently common to include with the main product. I've certainly needed it pretty much everything I've worked on.

> I guess I just feel like, if I'm at the point where I'm
> creating my own admin interfaces for everything, why include all that
> extra bloat?

I don't think everyone will create their own admin interfaces for everything. Plenty of people will be happy with an out-of-the-box UI for internal business functions.

As a related point, what about ModelAdmin? This is something that plenty of people find useful and makes total sense in a outside of the managed-cotnent context.

Finally, would you feel differently if you actually liked the design of the out-of-the-box UI, and/or it was easily extendable and themeable, both of which are goals for SilverStripe 3?

> I think as a starting point, I would say we should aim to keep a
> framework invisible.

...

> You shouldn't be able to tell your colleague what
> Sapphire looks like, or what Symfony looks like.

I disagree; comparisons to Symfony aren't relevant because this is a way that we can differentiate ourselves.

> You may have misunderstood me... I certainly don't want a framework
> that lean.

I was simply trying to explain the logical consequence of saying "No UI". The Forms systems *is* UI, especially the more complex fields.

[Uncle Cheese]

Well, like I said, I don't think {$Anything}Admin belongs in the
framework, but maybe that's just me. When it comes to SilverStipe, I'm
as pious as they come, so I know I'll love and continue to use
exclusively whatever you guys come up with. Just sharing my thoughts!

-UC

[Martijn Van Nieuwenhoven]

I agree with the fact the UI is a matter of taste and should be flexible enough to change, for example by adding templates like we do for our frontends. And yes an admin panel with the default bloat of CMS main (nd DataBase, most tables come from the SiteTree (and versioning) system right?) but with mininal asset and security admin. In all my apps, that might not needed a SiteTree, I always needed a managable location to store some files and lock data behind a password.

I think an empty LeftAndMain as you get when you just extend LeftAndMain without any methods is a great way to start building you own adminpanels. Ok, you might be limited to the Left (collections/navigation) Right (detail/editscreen) setup, but when we can add our custom templates for the admin, that should be fixed.

What I really like about Silverstripe, besides the CMS, is that I can write like 15 lines of code to connect 3 DataObject with correct relations and SS will scaffold my forms and an Admin on the fly as a startingpoint. (You should really try to get the same functionality that in Joomla ;)). With a heavily extended ModelAdmin Im able to create any left or rightpane I want.

So if talking for myself, I agree Sapphire should have at least assets and users and a basic admin to manage them, without the need for the complete SiteTree/CMS, but I dont want to reinvent the weel every project again.

Maybe the asset and user code could be shipped with sapphire, but it is disabled by default, but I can toggle on when I need it with a single line of code. And when I do decide I need the CMS anyway it will toggle the asset and useradmin in the same way.

As with the bloated MemberTable when using Decorators. I never understood why we should use a Decorator for assigning Data to a Member. If you have a Forum and a Webshop and another custom module the Membertable can explode with datafields. When you want to edit a ForumMember you are confronted with all the Webshop Fields and they other way around.

Thats why I think a ForumRole should has_one Member and a Customer should have_one Member (or not when they don't want an account). And in the ForumAdmin you have the ForumFields and in the ShopAdmin you have the ShopFields to edit, nothing more.

So to the point: strip Sapphire, but give me asset/security and a simple backend to manage it. I will take care of the rest, and if I want my own UI, give me a location where I can drop my theme..

Cheers.

[Martijn Van Nieuwenhoven]

PS, mind the typos :)

[Ingo Schommer]

I've created two tickets detailing the migration, specifically around all the dependencies involved in moving SiteTree to cms, and LeftAndMain (without CMSMain) into sapphire.

http://open.silverstripe.org/ticket/6519

http://open.silverstripe.org/ticket/6520

These tickets complement Will's patch that started the decoupling in http://open.silverstripe.org/ticket/6281

Previous comments mentioned the ability to work with a "bare bones" sapphire, without any admin interfaces at all.

My suggestion is to accomodate this by moving admin related classes into a new sapphire subfolder,

rather than weaving them into the existing folder structure - this makes it easy to remove the dependency

later on, and for developers to remove the directory manually for now. Effectively, its a module within a module.

We'd try to keep the dependencies from sapphire classes to this "admin module" low,

which would allow us to separate them easily once we have a proper module manager.

sapphire/

  ...

  forms/

  templates/

  tests/

  javascript/

  admin/

    ...

    forms/

    templates/

    tests/

    javascript/

Is it worth the inconsistency in having templates, css, images in separate locations throughout sapphire?

Does sapphire/admin work for naming?

To be clear, this is not an opportunity to restart the discussion about the theoretical benefits of sapphire vs. cms,

but rather a pragmatic approach to allow a flexible usage of sapphire as a standalone framework.

[Sam Minnee]

> Is it worth the inconsistency in having templates, css, images in separate
> locations throughout sapphire?
> Does sapphire/admin work for naming?

Yes, I think this is great.

[Frank Mullenger]

This is a bit off topic but I have been using LeftAndMain for a custom admin area built into a module recently and finding LeftAndMain fairly difficult to get my head around and work with. 

Whats in the pipeline for LeftAndMain in the future? From what I understand the Prototype js lib is being removed in favour of jQuery, but I'd also like to know if there is any focus on making it a bit easier to add a basic admin area in the CMS with links in the _left panel and a form or html content in the _right panel all submitting via AJAX? 

And whether there will be a straight forward example for achieving this, at the moment the random links tutorial is the only one I can find but it seems a little dated and doesn't cover something like displaying an EditForm in the _right panel and submitting that form via AJAX (http://doc.silverstripe.org/old/private:tutorial:creating-a-module).

[Sam Minnée]

> Whats in the pipeline for LeftAndMain in the future? From what I understand the Prototype js lib is being removed in favour of jQuery, but I'd also like to know if there is any focus on making it a bit easier to add a basic admin area in the CMS with links in the _left panel and a form or html content in the _right panel all submitting via AJAX?

It's getting an overhaul, and it will be more extensible. Stay tuned! I'd recommend that you try out the alpha of SilverStripe 3 once it's released and give us feedback if you think that the API can be improved.

[Frank Mullenger]

Thanks, sounds good, really looking forward to SS 3 - you guys are working hard cheers!

On Tue, Mar 15, 2011 at 10:22 AM, Sam Minnée <s...@silverstripe.com> wrote:

> Whats in the pipeline for LeftAndMain in the future? From what I understand the Prototype js lib is being removed in favour of jQuery, but I'd also like to know if there is any focus on making it a bit easier to add a basic admin area in the CMS with links in the _left panel and a form or html content in the _right panel all submitting via AJAX?

It's getting an overhaul, and it will be more extensible.  Stay tuned!  I'd recommend that you try out the alpha of SilverStripe 3 once it's released and give us feedback if you think that the API can be improved.

--