On 16/03/2010, at 4:37 PM, Xavier Shay wrote:
> If you must store them in the DB, perhaps consider a separate table for
> unconfirmed entries. It's conceptually clearer and a much nicer way of DRYing
> thing up.
Creating a *duplicate* table for storing unconfirmed records is DRY? See,
madness!
On 16/03/2010, at 6:06 PM, Nathan de Vries wrote:
Creating a *duplicate* table for storing unconfirmed records is DRY?
See, madness!
Say you're building a cart checkout process and you'd like a
shipping & payment details confirmation screen ("Please verify that
the following shipping & pa
On 16/03/2010, at 5:54 PM, Xavier Shay wrote:
> In which I wave my hands a lot. I haven't thought this through totally, but
> thought I'd throw it out there.
>
> Problem:
> - My specs are slow oh no!
> - Setting up objects/object trees takes heaps of time
> - There's a *lot* of duplication in ob
I think all is there to make it happen, you just need to track object
changes -which AR does with #changed? and such.
Would love to see it happen, though I'm afraid I don't have time atm
to help.
--
Pat
On 16/03/2010, at 6:48 PM, Ben Hoskings wrote:
On 16/03/2010, at 5:54 PM, Xavier Sha
Hi Rails Community,
Thanks for all of your responses. It's great to see a vibrant community!
Must head down to one of your local meets.
I actually have done what Ben and Nathan have suggested => That is hidden
fields on a confirmation page which is posted again.
I think perhaps my original quest
This sounds like an interesting challenge. But, I like to keep my
tests super stupid and your hand waving solution hurts my head. What
about throwing the tests at a cluster or something?
*hands waving* Buuut, say I was to bite... an easy win would be to
take a snapshot at the end of a setup block.
This is a little OT, but:
I'm a little bit leery of default_scope because of my experience with
is_paranoid - both the issues outlined in the author's note here
http://blog.semanticart.com/2009/10/13/killing-is-paranoid.html and several
pretty nasty gotchas working with is_paranoid. Some of them w
Hi Rails Community,
Thanks for all of your responses. It's great to see a vibrant
community! Must head down to one of your local meets.
I actually have done what Ben and Nathan have suggested => That is
hidden fields on a confirmation page which is posted again.
I think perhaps my original quest
It might be worth thinking about this in a similar vein to the db:seed task
(intended to be used to install data required for development / prod, but
I've used it for test "fixtures" before).If you combine some records crafted
with 'plausible / memorable scenarios' in mind with a sugary accessor or
On 16/03/10 6:06 PM, Nathan de Vries wrote:
On 16/03/2010, at 4:37 PM, Xavier Shay wrote:
If you must store them in the DB, perhaps consider a separate table for
unconfirmed entries. It's conceptually clearer and a much nicer way of DRYing
thing up.
Creating a *duplicate* table for storing
Hi all,
I want to add authorization to my application. The hierarchy would be
very simple, which is only admin or not. I saw this gems called
Lockdown that also works nicely with Authlogic. I've taken a look at
the tutorial and quite impressed with how it works. But is Lockdown
too much for simple
On 17/03/2010, at 8:14 AM, Xavier Shay wrote:
> the data has very different profiles - unconfirmed orders are pretty much
> transient/throw away, where as a confirmed order needs to stick around.
>
> This becomes *especially* relevant when you start getting more than one
> 'confirmed_at' type co
Hi Joshua,
We use Lockdown for a high security site and personally I think it is
a overkill for your use (admin or not). We end up forking Lockdown and
simplify it further to suit our needs. Plus, Authlogic and Lockdown
integration is not as simple as it looks. We ditched Authlogic in the
end.
Bo
*cough* pimp *cough*
http://github.com/juliocesar/has_factual_roles
But on a more serious note, check cancan from Ryan Bates:
http://github.com/ryanb/cancan
His is actually good.
On Wed, Mar 17, 2010 at 10:45 AM, phan.anh...@gmail.com
wrote:
> Hi Joshua,
>
> We use Lockdown for a high securi
A supposedly easy migration is to change acts_as_paranoid to acts_as_archived.
Same API, but uses a different table for the deleted records.
I say supposedly as I haven't actually used it yet.
On 17/03/2010, at 10:07 AM, Ben Hoskings wrote:
> On 17/03/2010, at 8:14 AM, Xavier Shay wrote:
>> the
Thanks Ody,
I'm going to look at both. Looks good. Thanks for sharing.
Cheers.
On Wed, Mar 17, 2010 at 10:56 AM, Julio Cesar Ody wrote:
> *cough* pimp *cough*
>
> http://github.com/juliocesar/has_factual_roles
>
> But on a more serious note, check cancan from Ryan Bates:
>
> http://github.com/r
FWIW (having no experience w/ Lockdown), my take on authorization is that
it's usually core application behaviour, such that the best approach is to
write your own "as simple as it can be, but no simpler" implementation using
common conventions.
I usually use restful_authentication as a base and
sure, the more the merrier as far as I'm concerned!
There's enough discrete parts to it that we can divide and conquer.
Depending on where peoples' interests lie, there's hacking on the
Eventmachine libs, writing the Jquery plugin(s), rspec / cucumber stories
and testing the client JS with somethi
On 17/03/2010, at 11:56 AM, David Lee wrote:
> FWIW (having no experience w/ Lockdown), my take on authorization is that
> it's usually core application behaviour, such that the best approach is to
> write your own "as simple as it can be, but no simpler" implementation using
> common convent
Sean and I are planning on coming along and doing some work on grafico (graphs
done with Rafaël): tie-graphs, waterfall graphs, variable-width bar charts and
some other things that need fixing...
http://github.com/suranyami/grafico
Does that appeal to anyone?
--
You received this mes
I'm certainly interested to see what you get up to.
--
You received this message because you are subscribed to the Google Groups "Ruby
or Rails Oceania" group.
To post to this group, send email to rails-ocea...@googlegroups.com.
To unsubscribe from this group, send email to
rails-oceania+unsubs
On 16 March 2010 17:54, Xavier Shay wrote:
> - Either some sort of profiling, where machinist records object creation and
> builds up a library (so first run will be just like normal, second run will
> be optimized)
Now that would be cool! But I have a question first:
Has anyone done any profili
On Wed, Mar 17, 2010 at 1:59 PM, Pete Yandell wrote:
>
> Has anyone done any profiling on their Rails app tests to work out
> where the time goes? I've always wondered how much of the time testing
> Rails apps is wasted on the database syncing disk writes, etc. If you
> threw your test database o
On 17/03/2010, at 2:29 PM, Pete Yandell wrote:
> Has anyone done any profiling on their Rails app tests to work out
> where the time goes? I've always wondered how much of the time testing
> Rails apps is wasted on the database syncing disk writes, etc. If you
> threw your test database on a ramdi
I've got something else to throw in: the sequential nature of cucumber
stories is kind of one of its selling points for testing certain
resource-intensive tasks.
You can write a feature as a long chain of little ops & assertions that
assume and build upon the state of the previous ones - sometimes
25 matches
Mail list logo
