refactor(DataObjectAsPage): Make this class more flexible #18
Conversation
|
By the way, in 3.0 the label associated with the "Title" field is "Page Name". |
Removes Content field Removes call to parent::getCMSFields so we don't get unwanted scaffolded fields Extracts field creation from getCMSFields into separate protected methods that derived classes can use them if they don't want to call parent::getCMSFields BREAKING CHANGES: Content field has been removed - derived classes will have to add this back themselves if it is needed. Scaffolded fields are no longer included in getCMSFields - derived classes can simply use an instance of FormScaffolder to achieve the same result.
|
OK, so I have reverted the urlSegment positioning back to underneath the Title field (and not inside the MetaData field). |
|
Happy to merge this now, but how should I merge without screwing up sites that use the Content field? Should I create a branch for the existing code them merge this into master? What would you call that branch? Cheers, Aram |
|
If you are talking about 3.0 branch (i.e. master) how many sites are On 12 November 2012 10:06, Aram Balakjian notifications@github.com wrote:
|
|
Yes, but they would then lose any existing content as it would be looking for it on a different table. I'm not sure how many people are using it. I only released it last week, but I assume if people were upgrading from 2.4 to 3.0 then they would still have the breaking issue at any point in the future. How would I define the Version numbers, with tags or branches? |
|
Generally, I would have a branch for every version that you are I am not clear how the Silverstripe ORM works. Can it not do that kind of Pete On 12 November 2012 10:18, Aram Balakjian notifications@github.com wrote:
|
|
Also, if you upgrade to a breaking change then you should expect to have to How about, as an alternative, you to create a new class that sits above the Pete On 12 November 2012 10:25, Peter Bacon Darwin pete@bacondarwin.com wrote:
|
|
There are a couple of other issues around the urlSegment in this change - particularly if there is no $this->ID. |
|
Ok cool. I think that would still break, because existing 'Content' would be in the DOAP table not the subclass. Just did a test and it does indeed just lose the content. |
|
How about writing a migration? http://api.silverstripe.org/trunk/framework/dev/MigrationTask.html |
|
Hmm, yea could do, but not much info on how to do it. Bearing in mind that SilverStripe will no longer be aware of the Content field in the DataObjectasPages table, so it would most likely need to be written in SQL. My Raw SQL has been spoiled by Sapphire ;) I'll take a look when I have a min though. Aram |
|
Actually thinking about this - perhaps my requirement is different from most other people's and in fact a Title and Content on a DataObjectasPage is a reasonable request. So I will revert that bit but I still think that factoring out each of the CMS fields bits is a good idea. |
|
Ok cool I think your right, you can always do a removeByName() to hide the field from the user. I know it's not ideal as you would have a redundent field, but it does keep it consistent with 'Page'. |
|
What I am actually thinking now :-) is that you could insert a new (bare On 15 November 2012 11:44, Aram Balakjian notifications@github.com wrote:
|
|
Hmm, it would still break people sites because it would have a new table that they didn't have as it would need URL segment on it along with all the versioning bits.... |
|
Hmm. OK. On 15 November 2012 11:56, Aram Balakjian notifications@github.com wrote:
|
|
By the way, is it not possible to stick a PageType into ModelAdmin? On 15 November 2012 11:57, Peter Bacon Darwin pete@bacondarwin.com wrote:
|
|
Possible but messy, you need to assign them a parent and then hide them from the site tree and menus. I did do this for one project but found it was cleaner to do it this way. Especially in SS3 I don't think there is an easy way to hide items from the site tree... |
|
Hey Aram, I found that if you stick a PageType into ModelAdmin, you lose the versioning/publish buttons & settings section when editing. Have you found a generic way to fix that? (DOAP uses versioning)... If so, I have a tiny module that allows to hide certain pages from the sitetree: https://github.com/micschk/silverstripe-excludechildren |
|
Hi Micschk, that will be to do with the getCMSActions issue with SS3, it doesn't call it in GridField which means it doesn't get called in ModelAdmin. DOAP gets around this by subclassing GridField components, take a look you should be able to use the same technique to get those buttons back for SiteTree items too. |
Removes Content field
Removes call to parent::getCMSFields so we don't get unwanted scaffolded fields
Extracts field creation from getCMSFields into separate protected methods that derived classes can use
BREAKING CHANGES:
Content field has been removed - derived classes will have to add this back themselves if it is needed.
Scaffolded fields are no longer included in getCMSFields - derived classes can simply use an instance of FormScaffolder to achieve the same result.