In your example, Sean, you create a StatsController that inherits from
ApplicationController (which is the default if you use Radiant's
controller generators). Anyway I've been getting all kinds of errors
with my specs and banging my head against a wall only to *finally*
realize that Applicati
On Jul 8, 2008, at 9:08 PM, Chris Parrish wrote:
Jim Gay wrote:
On Jul 8, 2008, at 8:16 PM, Chris Parrish wrote:
Since the all / find / require_all / inclusive attribute is both
required and boolean (yeah I know XOR's been mentioned but I'm not
going there), why not try to include that co
Jim Gay wrote:
On Jul 8, 2008, at 8:16 PM, Chris Parrish wrote:
Since the all / find / require_all / inclusive attribute is both
required and boolean (yeah I know XOR's been mentioned but I'm not
going there), why not try to include that condition in the rest of it
somehow?
(notice that t
On Jul 8, 2008, at 8:16 PM, Chris Parrish wrote:
Since the all / find / require_all / inclusive attribute is both
required and boolean (yeah I know XOR's been mentioned but I'm not
going there), why not try to include that condition in the rest of
it somehow?
(notice that the name "part
Since the all / find / require_all / inclusive attribute is both
required and boolean (yeah I know XOR's been mentioned but I'm not going
there), why not try to include that condition in the rest of it somehow?
(notice that the name "part" is singular)
So in this example, you'd have 3 diff
On Jul 8, 2008, at 2:43 PM, Tim Gossett wrote:
On Tue, Jul 8, 2008 at 2:27 PM, Sean Cribbs <[EMAIL PROTECTED]>
wrote:
Or I'm thinking that inclusive="true" might be good since we've
got mostly
true/false for extra attributes on r:content
[inclusive="true|false"]>
inclusive="true" being t
On Tue, Jul 8, 2008 at 2:27 PM, Sean Cribbs <[EMAIL PROTECTED]> wrote:
>
>
>> Or I'm thinking that inclusive="true" might be good since we've got mostly
>> true/false for extra attributes on r:content
>>
>> > [contextual="true|false"] />
>> > [inclusive="true|false"]>
>> > [inclusive="true|false"]
On Jul 8, 2008, at 2:27 PM, Sean Cribbs wrote:
Or I'm thinking that inclusive="true" might be good since we've got
mostly true/false for extra attributes on r:content
[contextual="true|false"] />
inclusive="true" being the default (meaning AND)
Would either of those be clear to everyone?
Or I'm thinking that inclusive="true" might be good since we've got
mostly true/false for extra attributes on r:content
[contextual="true|false"] />
[inclusive="true|false"]>
[inherit="true|false"] [inclusive="true|false"]>
inclusive="true" being the default (meaning AND)
Would either of
On Jul 8, 2008, at 2:11 PM, Tim Gossett wrote:
On Tue, Jul 8, 2008 at 12:16 PM, Jim Gay <[EMAIL PROTECTED]> wrote:
#this being the
default
Or
#this being the default
When I see "collect," I expect an array to be returned. I think
"find" is
the way to go. Even though find(:all) and
Sean, what do you think?
I think either
#this being the default
Or I'm thinking that inclusive="true" might be good since we've got
mostly true/false for extra attributes on r:content
[inclusive="true|false"]>
inclusive="true" being the default (meaning AND)
Would either of those be
On Tue, Jul 8, 2008 at 12:16 PM, Jim Gay <[EMAIL PROTECTED]> wrote:
>
> #this being the default
>
> Or
> #this being the default
>
>
When I see "collect," I expect an array to be returned. I think "find" is
the way to go. Even though find(:all) and find_all_by_* return an array, I
think it's
I have to agree with Tim in this. I'm traditionally bad at picking
names for things like attributes but I think that its critical that
the meaning be clear; Find and collect strike me as being ambiguous, I
though of require but that's overloading an important word.
Adam
On 8-Jul-08, at 10:2
> Or better yet
> #this being the default
>
> Or
> #this being the default
>
>
This looks like the best solution to the AND / OR discussion.
--
Tim
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/se
This
Stuff
is already implemented for the next version and I think is best served
as a shortcut for your
Stuffr:if_content>
I added a similar feature to the radiant-tags-extension (http://github.com/jomz/radiant-tags-extension/tree/master
) to what you are suggesting.
In that extension you ca
We should definitely strive for clarity above all. The behavior should
be explicit or readily apparent in the written tag and the ambiguity of
OR vs. AND in this case worries me. Is there perhaps a more elegant but
less general solution?
Sean
Adam van den Hoven wrote:
Actually I think you n
Actually I think you need to rethink things a bit. Specifically, I
think that specifying multiple parts should be handled in an OR
fashion. The reason is that there would be no way to create a
div.sidebar if either a marketing or callout part exist and then put
one or both of those part in
17 matches
Mail list logo
