Hi,
I'm just new to Ruby but after only a few hours I can see that I want
to switch from PHP to Ruby. Rails is so good! 
I was getting involved with a SourceForge project to write a modern
version of osCommerce with MVC, ORM, CSS layout etc. But I think I'd
rather work in Rails. Is there already an open source project like
osCommerce in the Rails world? If not where do Rails open source
projects usually reside? Something like SourceForge?
Thanks,
Peter
Anyone interested in joining a new open source project to write this? I
wrote down a few thoughts
http://members.shaw.ca/petermichaux/store/store-rb.html
-Peter
Hi,
There seem to be people interested in a project something like
osCommerce in the Rails world. Enter "store.rb"! You can check out the
please visit the project website
http://trac.vaillant.ca/store.rb/wiki
please join the mailing lists
http://rubyforge.org/mail/?group_id=1046
The team is forming and the project is getting underway!
I look forward to collaborating!
-Peter
store.rb - the killer ecommerce app for Rails!
http://trac.vaillant.ca/store.rb/wiki
Search the list archives for oscommerce, there is at least one good long
thread there with some good ideas on this. So far no one seems interested
enough to actually write it though. IMO it's going to take one person to get
the ball rolling and be able to get out an initial release on their own.
That just seems to be how it goes..
Chris
On 10/20/05, petermichaux@yahoo.com <petermichaux@yahoo.com> wrote:
Anyone interested in joining a new open source project to write this? I
wrote down a few thoughts-Peter
Hi Peter,
Yes. I'd like to help with the database part at least (to make it non-MySQL
dependent).
On 10/20/05, petermichaux@yahoo.com <petermichaux@yahoo.com> wrote:
Anyone interested in joining a new open source project to write this? I
wrote down a few thoughts-Peter
I think it's better to extract a framework from an existing store,
than to try to build a generalized framework from scratch.
On 10/20/05, petermichaux@yahoo.com <petermichaux@yahoo.com> wrote:
Anyone interested in joining a new open source project to write this? I
wrote down a few thoughts-Peter
Isn't that for-free with Rails?
Douglas
2005/10/24, Corey Lawson <corey.ssf.lawson@gmail.com>:
Yes. I'd like to help with the database part at least (to make it non-MySQL
dependent).
Joe Van Dyk wrote:
I think it's better to extract a framework from an existing store,
than to try to build a generalized framework from scratch.
This is what I want to do. I'm planning on building a demo store that
uses all the application features. The demo store is essential to
making sure that the application works well. Then someone implementing
the application can change the database data, images, css, store
options and extend the functionality if they have a particular need.
Then they are in business.
Douglas Livingstone wondered:
Yes. I'd like to help with the database part at least (to make it
non-MySQL
dependent).Isn't that for-free with Rails?
Douglas
Sort of. It's not fool-proof, though, especially if you use big magical
find_by_sql queries.
Also, for an app like this, you will need a script to create the database,
and that is platform-specific. Although Og provides this capability, and
there's also a separate Schema Generator (designed for Rails use) on
RubyForge.
Cheers,
Dave
2005/10/24, Corey Lawson <corey.ssf.lawson@gmail.com>:
Unless you by "existing" you mean one that exists today. If you mean
this then which existing store? Is there a good, open source store app
that is avalible?
No. The OpenCommerce database schema isn't very Rails-friendly. Some people
would probably like to use something besides MySQL, too.
On 10/24/05, Douglas Livingstone <rampant@gmail.com> wrote:
2005/10/24, Corey Lawson <corey.ssf.lawson@gmail.com>:
> Yes. I'd like to help with the database part at least (to make it
non-MySQL
> dependent).
>Isn't that for-free with Rails?
Douglas
Well, I'd probably throw the schema into DeZign, and generate database
scripts from there.
On 10/24/05, Dave Burt <dave@burt.id.au> wrote:
Douglas Livingstone wondered:
> 2005/10/24, Corey Lawson <corey.ssf.lawson@gmail.com>:
>> Yes. I'd like to help with the database part at least (to make it
>> non-MySQL
>> dependent).
>>
>
> Isn't that for-free with Rails?
>
> DouglasSort of. It's not fool-proof, though, especially if you use big magical
find_by_sql queries.Also, for an app like this, you will need a script to create the database,
and that is platform-specific. Although Og provides this capability, and
there's also a separate Schema Generator (designed for Rails use) on
RubyForge.Cheers,
Dave
Corey Lawson wrote:
No. The OpenCommerce database schema isn't very Rails-friendly.
What parts do you think stand out as not rails-friendly?
I'm all for a new schema anyway to add more flexiblity and functionality
table names...PK field names, but that could be configured around with AR, I
suppose. The schema also might need some normalization.
It has a few history/audit tables, and it would be better to set these so
they're populated via triggers instead of by the application layer.
Since the Depot application already does the core of OSCommerce (i.e.,
catalog, orders), I think the quicker way would be to borrow functionality
from OsC and add it to Depot.
On 10/25/05, petermichaux@yahoo.com <petermichaux@yahoo.com> wrote:
Corey Lawson wrote:
> No. The OpenCommerce database schema isn't very Rails-friendly.What parts do you think stand out as not rails-friendly?
I'm all for a new schema anyway to add more flexiblity and functionality
Per what a number of others have discussed, auditing/triggers are
better done in the application layer. In particular, for portibility,
MySQL < 5.0 doesn't have support for triggers, and most databases that
support triggers support them in their own way vs in the application
layer were it is consistent regardless of database.
Also, I'm thinking that it doesn't hurt to borrow functionality ideas
from as many projects as possible, but borrowing actual structure and
code can lead to being restricted by the other projects design
desicions and in particular, limitations in the implementation language
which might be other then ruby.
Here is David Heinemeier Hanson's thoughts about why it is best to keep
the database dumb
http://www.loudthinking.com/arc/000516.html
-Peter
store.rb - the killer ecommerce app for rails!
http://trac.vaillant.ca/store.rb/wiki
As much as I respect David's work on Rails, he can't be more wrong on
this matter -- *unless* you're talking a single-app database. The
moment you need more than one application talking to your database,
those constraints he considers "wrong" are vital.
There are a number of good reasons to have strong constraint support
in the database. I mostly agree with him about putting business logic
in the database -- but that's triggers and stored procedures, not
constraints. There are, however, times when it is important to have
that sort of behaviour available.
-austin
On 10/26/05, petermichaux@yahoo.com <petermichaux@yahoo.com> wrote:
Here is David Heinemeier Hanson's thoughts about why it is best to keep
the database dumb
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
Frankly, I trust postgresql more than I do rails to ensure the integrity of
my data. I'll keep my constraints thank you:)
Chris
On 10/26/05, Austin Ziegler <halostatue@gmail.com> wrote:
On 10/26/05, petermichaux@yahoo.com <petermichaux@yahoo.com> wrote:
> Here is David Heinemeier Hanson's thoughts about why it is best to keep
> the database dumb
>
> http://www.loudthinking.com/arc/000516.htmlAs much as I respect David's work on Rails, he can't be more wrong on
this matter -- *unless* you're talking a single-app database. The
moment you need more than one application talking to your database,
those constraints he considers "wrong" are vital.There are a number of good reasons to have strong constraint support
in the database. I mostly agree with him about putting business logic
in the database -- but that's triggers and stored procedures, not
constraints. There are, however, times when it is important to have
that sort of behaviour available.
David's argument is for a single-app database, because he doesn't
believe that applications should integrate directly with each other's
databases. As such, all databases are single-app databases.
The alternative being integration by specific hooks, RPC, object
brokering, etc might take more time, yes, but is also ultimately more
flexible. Systems do not have to be physically as near and the
protocols used can be much better protected. HTTP, used by SOAP and
XMLRPC for example, is far easier to secure and firewall then SQLnet
used by Oracle.
This ultimately boils down to a difference in opinion on design.