SilverStripe Development Google Group

Merged jsrewrite feature branch to trunk

i...@silverstripe.com (Ingo Schommer) — Mon, 23 Nov 2009 20:41:29 UT

Hello there,

I've merged a long-standing feature branch back into SilverStripe
trunk this weekend: jsrewrite.

You can read about our motivations, summarized changes etc in a
previous thread:
[link]

RE: SS with awstats

bubap...@gmail.com (Rob) — Wed, 18 Nov 2009 21:58:01 UT

Hi all,

Having some issues with setting up awstats with SliverStripe.

From what I've read i need to add something in my .htaccess file.

Does any one know what i should be added into my .htaccess file? its
currently in the /statistics/

Thanks

Re: Announcing Concrete - a jQuery library for structured code development

ham...@silverstripe.com (hamish@silverstripe.com) — Wed, 18 Nov 2009 20:41:14 UT

Just to let people who aren't following the jQuery Concrete group
know, there's currently a vote going on there to pick a new name (a
trademark holder has politely requested I change names to avoid
confusion).

You can see the suggestions, read the ridiculously complicated voting
rules and even participate in the vote (although you'll need to join

Re: DB Abstraction

sam.min...@gmail.com (Sam Minnee) — Wed, 18 Nov 2009 20:35:40 UT

I guess the issue right now is that the ORM and Database layers are a
little too meshed together.

Loosely, the Database class and its subclasses handle the querying and
low-level query generation, using either SQLQuery objects or special
arrays passed to Database::manipulate() as the intermediate

Re: DB Abstraction

dale.lis...@gmail.com (dalesaurus) — Wed, 18 Nov 2009 17:30:23 UT

I was not aware, that is great! Retract anything nice I said about
integrating other ORMs into SilverStripe and roll it into the hype for
2.4.

And Marcus, isn't half the fun of programming making sure you don't
forget [insert particular language nuances here] when pounding out
code? :)

Re: DB Abstraction

sam.min...@gmail.com (Sam Minnee) — Tue, 17 Nov 2009 23:26:56 UT

SilverStripe 2.4 has support for PostgreSQL and MSSQL. The connectors
for these databases are packaged as separate modules.

Re: [silverstripe-dev] Re: DB Abstraction

nyeh...@gmail.com (Marcus Nyeholt) — Tue, 17 Nov 2009 23:22:55 UT

It's probably important to note the distinction between the ORM
functionality (mapping of objects and their relationships to DB tables) and
the actual code that deals with querying/updating the database. I don't
think the ORM side of SS needs to change at all, I was more interested in
how the underlying DB layer deals with the actual mapping of ORM

Re: DB Abstraction

dale.lis...@gmail.com (dalesaurus) — Tue, 17 Nov 2009 16:37:09 UT

I rather like SS's light ORM approach and smooth integration with the
templating system. It was one of the reasons I jumped in. Zend_Db/
Repose/Outlet/Doctrine/Propel/ etc are all good systems but I have yet
to find something I can't do with SS's built in facilities. Plus the
idea of SS becoming a Frankenstien of libs that depend on libs make it

RE: [silverstripe-dev] Re: DB Abstraction

bacondar...@googlemail.com (Pete Bacon Darwin) — Tue, 17 Nov 2009 09:59:39 UT

I raised this earlier and while I still think that it would be preferable to move to a third party provider, none of the standard ORMs provide the facilities that Sapphire requires: most importantly an effective inheritance mechanism (this is fundamental to the way the CMS works) and also aspect oriented techniques such as DataObjectDecorators. In the long run my preference would be to choose a solid third party ORM and work with them to add these elements.

Re: [silverstripe-dev] Re: DB Abstraction

m.lewis.ever...@googlemail.com (Morven Lewis-Everley) — Tue, 17 Nov 2009 09:38:06 UT

At the moment I don't have to many issues with the Silverstripe ORM, but in
my mind, moving over to a third party library would make sense from a purely
practical standpoint.

If the ORM was maintained by a third party (eg Zend), then it means that the
Silverstripe devs can use the time they would spend developing that focusing

Re: SilverStripe 2.4-alpha1

sam.min...@gmail.com (Sam Minnee) — Tue, 17 Nov 2009 03:07:28 UT

It's difficult to determine at this stage because it really depends on
how much feedback we get about problems that people run into upgrading
to 2.4. We'll post back when we have more info.

Re: DB Abstraction

sam.min...@gmail.com (Sam Minnee) — Tue, 17 Nov 2009 02:04:38 UT

Hi Marcus,

I guess the main reason is that the Database layer is fairly tightly
integrated with ORM. One of my half-done "yea I should really put
more time into that sometime" side-projects has been to refactor the
ORM to allow for methods like this:

DataObject::get("Group")->filt er(array(

DB Abstraction

nyeh...@gmail.com (Marcus Nyeholt) — Tue, 17 Nov 2009 01:32:49 UT

Disclaimer - I'm new to SS, please don't shoot me if this is already in
under the covers somewhere :). I guess the overall question is something
more like "How can I just let silverstripe take care of all the mapping
between a filter I specify and the different underlying DB implementations
of field/identifier quoting, pagination etc?".

Re: [silverstripe-dev] Re: SilverStripe 2.4-alpha1

m.lewis.ever...@googlemail.com (Morven Lewis-Everley) — Mon, 16 Nov 2009 11:34:29 UT

I wouldn't mind knowing this as well. For similar reasons.

Re: [silverstripe-dev] Re: SilverStripe 2.4-alpha1

webbo...@gmail.com (Matt Bower) — Fri, 13 Nov 2009 20:06:14 UT

What is the timeline goal for the stable 2.4? I have a client project that could really use the hierarchical URLs but the project timeline may not be conducive to use 2.4.

Thanks.

Matt