Jump to:

17452 Posts in 4473 Topics by 1971 members


SilverStripe Forums » Archive » Too many subpages slowing down interface

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, biapar, Willr, Ingo, simon_w

Page: 1 2 3 4 5
Go to End
Author Topic: 38756 Views
  • Rich
    Community Member
    1 Post

    Re: Too many subpages slowing down interface Link to this post

    This is relevant to my interest.

    I recently found SilverStripe and am testing it out for as a possible framework to create a new website for the 82nd Airborne. I know that within a few months, it will have a few hundred if not thousand articles.

    I love this platform so much more than Joomla, and would like to see one of the afore mentioned solutions developed. As mentioned before, a combination of both would be great. I could make it a site default to only return the entries for the past month or two weeks, and dynamic grouping takes care of the rest. Of course, any of these options/filters can be changed on a by user basis.


  • Sam
    679 Posts

    Re: Too many subpages slowing down interface Link to this post

    For anyone who is interested in trying to implement dynamic grouping, I have posted an implementation guideline here: http://doc.silverstripe.com/doku.php?id=recipes:customising-the-hierarchy#dynamic_grouping

    It's a pretty challenging piece of work, but it's doable.

  • zyko
    Community Member
    66 Posts

    Re: Too many subpages slowing down interface Link to this post

    Hi guys,

    I've a lot of typo3 websites running.
    the backend in typo3 3 is the best i can imagine.

    maybe you can take a few things out of there.


    this is done using the following things, which would be fine for a silverstripe redesign.
    i'll try to translate things into silverstripe words:

    * Any DataObject should include a 'has_one' to a SiteTree Entry (Page)
    * Someone can specify a PageId, where new DataObjects will 'take place'
    if not a CMS-user creates such a record on a SiteTree.
    (fe: for guestbook)
    * Rights on db-Fields for cms-users should be defined within User-Groups
    there's a need for a 'std-getcms-fields' implementation which
    will knock out fields a user can't see.
    * viewable ways for fields should be seperated from 'form building'
    (anyone can do this, of course for himself, also now)
    * then there should be a 'view all DataObject' Form attached to any SiteTree Element
    where user can filter for 'type' of DataObject and specify db-field filter values
    he has the right to see.
    and he should be capable to define the fields, he wants to see in the list.
    pagination, etc...
    If then 'clipboard' and 'editing only subset of column values' within the list
    from typo3 would also be available, it would be christmas-day ;-)
    * then editing one DataObject meens Popup 'std-getcms-fields' implementation
    which will show these fields he is alowed to change.
    * When 'querying' DataObjects on the frontend, one could define a 'starting' point
    where to look for records AND a 'nesting level' how deep 'childs of the SiteTree'
    would be searched too for these records.
    This is the simplest way to seperate instances for multiple cms-users.

    Don't misunderstand me.
    but backend till now is a little weak...
    Of course a few of these things cany anyone do for himself.
    but a general 'backend-DataObject' admin tool would be
    cool for anyone to have...


  • Sam
    679 Posts

    Re: Too many subpages slowing down interface Link to this post

    Hi Helmut,

    Most of this stuff can be done by site developers - the tutorials cover how to do this:

    There are a few points that you mentioned that we are doing some work on:

    * We are looking at developing more fine-grained permission control on the DataObjects and have that drive the forms generated.
    * We are also looking at automatically adding fields to getCMSFields() when you create $db, $has_one, $has_many, or $many_many entries.

    However, a complex data-querying interface is unlikely to ever make its way into the core CMS.

    SilverStripe CMS is Designed For Content Authors. Not developers. We really dislike the fact that other CMSes bolt developer-only functionality into the CMS and it gets in the content authors' way. It is much more important to us to have an interface that doesn't stand in the way of authors updating content.

    SilverStripe is built on the philosophy that there are a number of different people who come together to make a website: designers, developers, authors. Each of these people already have tools that enjoy using to do their job.

    In particular, designers and developers have PHP and HTML/CSS development tools. So, we let them use those to build a SilverStripe site. Not the CMS interface. That is for the authors.

    What this means is that a lot of development work on your site needs to be done in template and code files. This is by design.

  • Sean
    Forum Moderator
    921 Posts

    Re: Too many subpages slowing down interface Link to this post

    Well said, Sam.

    The "scaffolding" of fields instead of manually defining them on getCMSFields() will be a huge time saver!

  • zyko
    Community Member
    66 Posts

    Re: Too many subpages slowing down interface Link to this post

    Hi Sam, Hi Sean,

    Nice to hear that you guys are working of some kind of scaffolding for silverstripe.
    I think that would'nt be too complicated just for Dataobjects to show the native values.
    of course relations will stay complicated forever ;-)
    You guys have done a goooooooood job on designing silverstripe.
    i like the way you do things with site-rendering and controls. a very powerful concept.
    sapphire is the best thing i've ever seen till know doing db-creation.
    at our company we do a lot of things using hibernate, which of course is perfect
    in mapping legacy things, but not a environment for doing things rapid.
    i don't like the 'ruby way' how to deal with db things. first create tables then have propertys.
    silverstripe is also a cms instead of developing ruby and doing a cms totally personally.

    this would only leave a few recommendations i'ld have for the product:
    * use guids for id's instead of integer
    (knocks out your problems with sitetree and dericed class instances
    and can be created on the client side (no save necessary to get id after insert)
    * use static function db() instead of static db()
    would leave place for users to internally have only one array with
    name, db-type, my-html-control, neede roup right, etccc
    and give back these things you need for db-creation by filtering out this
    'meta array'
    i've seen a sample where one of you guys did something similar,
    but this is not dry, because the 'name' apperas in two lists
    which leads to have to maintain two lists.
    (i'm not a php guru, maybe static db could be also be replaced now
    with a static function getdb?)
    * members and groups, i never understould, why editing a member
    doesn't allow to select out of 'many groups'
    * best thing to have would be a additional control to play with 'relations'
    fe. for a Foo has_one Bar (means BarID column in dbtable Foo)
    if showing Foo in a (popup) FORM this should show
    the current 'Name' if something is 'related'.
    nearby a Button [...]
    if someone cklick the button, a 'search Form' opens above the current Form
    there i could search for this 'class' using a few parameters.
    i'ld mark the relevant element out of the search result,
    the 'seach window' closes, and gives back the BarId to the original Form.
    Same things could be for a has_Many
    there would be a list, search form opens selection means add this to the original list
    another '-' button would allow to knock out an entry from a list
    (not delete the entry)
    and if the search form would also allow to create new entrys
    then there would be a megacool system available ;-)

    yeah a know something sound's like 'a lot of work'
    don't misunderstand me, i'm for sure one of the biggest silverstripe fans!!!!
    but maybe you can take a few ideas for a further relase of your product...


  • Sam
    679 Posts

    Re: Too many subpages slowing down interface Link to this post

    As you suggest, we are developing scaffolding for all kinds of relations - has_one, has_many, and many_many. Stay tuned for version 2.3 - it will be quite an exciting release!

    I also hear what you're saying about having the configuration information for the database defined in one place. I don't know if converting the static variable to a method is the best solution, but we'll be considering ways of grouping together configuration options more logically.

  • zyko
    Community Member
    66 Posts

    Re: Too many subpages slowing down interface Link to this post

    Hi Sam,
    cool to hear
    and for sure, i'll stay tuned ;-)


Page: 1 2 3 4 5
Go to Top

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.