Kent,
We're working on it. 1.1.6 should fix it I believe. Someone on the
core chime in?
Yes, 1.1.6 is not vulnerable as far as we can tell. In future, this
list is *not* the place to report vulnerabilities. Perhaps we should
have a [EMAIL PROTECTED] which contacts a few of us on the core
te
I agree that the patch has some junk on it, sorry. I'll clean it up
and post in trac.
I haven't found any satisfying inheritance plugin out there and imho
it would be nice if AR would support other inheritances types right in
the core, but even if there's no intention of incorporating other
inheri
So here's my question... why does update_attributes run a new SELECT query,
and why is it using all those unnecessary conditions? I was even running
into an issue where sometimes the SELECT query wouldn't find what it was
looking for and therefore the update never happened (which is why I started
For example I just submitted a documentation patch
(http://dev.rubyonrails.org/ticket/5762) for the :from option for the
ActiveRecord find method. I'd think that adding support for this
option should have had documentation associated with it when it was
added to begin with.
Just me 2 cents.
Tr
I have a need to add additional conditions to the automatically
generated routes. Has anyone else come across this? Are there any
solutions in the works or any that people have already found?
What's the need that you have?
--
Cheers
Koz
___
Rails-cor
p = Person.find(:first)
p.school # nil
p.school_id = School.find_by_name('High School').id
p.school.name # High School
You should be assigning .school= here. Why are you working with the id?
p.school_id = School.find_by_name('Primary School').id
p.school.name # High School <= Shouldn't this b
Performance hurt. Having write_attribute mark dirty[attr] = true
would be great, but attributes may be modified in-place once they're
read, so we have to hash or copy them and look for changes.
A seductive alternative to is to treat attribute values as immutable
- freeze the value returned from r
> If I am remembering correctly, maybe he could share what the issues were
before someone dives into implementing a plugin for this.
Assuming you want to use dirty checking to write out a subset of the
columns for a given row, then the major reason to avoid it is data
integrity. You have no gu
I would *love* to PDI field level change checking (I've done it before
on another framework) and also updating Base to only UPDATE fields that
have changed. While it may sound funny, I'm a gung-ho person and would
just need to be pointed in the direction of how to make a plugin. I
wander through
That would depend on how they decide to implement it. If they use the
same method to warn about all deprecations, changing it to raise
would be as simple as overriding that method.
This has been committed now.
As you can see from deprecation_test.rb in activesupport, it's fairly
easy to monkeyp
That would probably be useful. I'd also like to see a rake task that
greps the app for deprecated calls. It might not be able to catch all
of them, but it should be able to find simple things like find_first
and @content_for_layout.
The grepping would actually be really difficult to make reliabl
On Jul 25, 2006, at 6:23 PM, Michael Koziarski wrote:
> So, what are people's thoughts about the warning methods, will it
> get your attention?
Works for me, especially if it has some link to what the preferred
way of doing things is.
My Thoughts there are that the api docs sho
Hey guys,
Rails has been around for a while, and it's about time we got serious
about deprecating APIs which we no longer intend to support. Without
getting into a discussion about which code precisely is going to be
deprecated, I thought I'd describe what's going to happen.
If you run your t
I'm in the process of fixing this, however trac and I have a
disagreement on whether or not it should work.
Any attempt to update the report appears to just delete the sql query.
I'll have someone else have a look at it, but in the meantime the
situation is now ... significantly worse ;)
On
Is there a reason why AR doesn't pass the guess year flag to parsedate when
casting columns? Seems to me, in the context of a DB date field, you would
always want the 4 digit year.
Right now, if you shove a date like: 07/18/06 to Rails, MySQL will get
0006-07-16, but ParseDate.parsedate('07/1
On 7/17/06, James Adam <[EMAIL PROTECTED]> wrote:
Since the behaviour is different from that of create (i.e. no object
instances are returned), why not just define a new method which
clearly indicates it's aptitude for inserting large amounts of data?
Model.import(hashes) or something...
The be
The ticket has a patch that shows how the API fits into the current
Rails code, with some fixes along the way (and more are coming).
We still haven't heard _a word_ from the core on the API.
Pretty please?
Hi Julik,
We have actually talked about this, sorry we didn't get back to you.
Trac's d
On 7/9/06, Jeremy Kemper <[EMAIL PROTECTED]> wrote:
On Jul 8, 2006, at 11:00 PM, Michael A. Schoen wrote:
> But just wondering if folks considered the performance impact of
> the change? From a simple test it seems that BigDecimal math is
> about twice as slow as using Floats.
BigDecimal is slow
On 7/8/06, Kevin Clark <[EMAIL PROTECTED]> wrote:
I don't think we should reduce that sort of spam. The point is that
it's annoying so it gets fixed. Maybe we can put something in the
subject though so those of us who don't care about oracle and pgsql
breaking can filter it out?
I think it'd be
On 7/5/06, Chris Mear <[EMAIL PROTECTED]> wrote:
Hello list,
In light of this recent change:
That's a strange change to embed in an oracle fix? Was it
intentional david? Michael?
http://dev.rubyonrails.org/changeset/4552
I personally don't like the change at all, the previous behaviour of
I think something like this may be more suitable for acts_as_legacy.
There are a myriad of enterprise naming standards (ZX_CST_ID__) and
we'll never support them all.
On 6/28/06, Obie Fernandez <[EMAIL PROTECTED]> wrote:
wtf? did I miss a previous discussion on this or something? That's an
ugly
> #xmlschema was aliased to #to_s for Date, which seems odd; making it
> work like Time#xmlschema seems to make more sense.
Can I get a commit on this? Any issues?
The .to_s was deliberate as the iso 8601 format for Dates without Time is
CCYY-MM-DD which is the same output as .to_s?
--
Cheers
Although the plugin author makes effort by packaging and releasing his stuff
to the community, not every plugin author will be able to support and
maintain his work on the mid or long term. As everyone here knows, the
coding part is only a slice in the lifetime of a piece of code, a tiner
slice th
I'm not entirely sure of the merits of having widely used plugins
report breakages back to the rails-core team. Some plugins are
notorious for fiddling with the internals of rails. Breakage there
is inevitable unless we freeze the codebase entirely.
Rails itself definitely needs some CI love,
Well, that is why I said that, if you filter them out, you need to create
separate reports for those. I never proposed for them to be cast aside and
forgotten, but if you don't deal with this then the effect will be the other
way around: they will make regular tickets sit ignored almost indefinite
> Yup, I'm not against doing away with proper patches. I'm against
> things like "It'd be nice if scriptaculous had a helper to make a web
> 2.0 application for me".
Then I misunderstood the message completely. I am 200% on to wipe the
"magic lantern" patches.
In hindsight, I communicated poorl
If you're overwhelmed with feature requests from a particular area, the
solution is not to force people to stop requesting. The solution is to use
Trac more effectively. Use filters, for christ sake! And it may be good idea
that some available Trac reports (
http://dev.rubyonrails.org/report) filt
On 6/3/06, Kevin Clark <[EMAIL PROTECTED]> wrote:
They're flooding the trac. Can Scriptaculous get a trac of its own or
can we direct non-patch enhancements to the spinoffs list and close
them? This is getting rediculous.
I also think this is getting completely out of hand. In addition to
mo
I can understand habtm is moving towards deprecating support for extra
attributes in join_table, and to use :through for those cases instead.
To clarify, patch for #5216 wasn't looking to support populating extra
attributes in join table. But rather, it was meant to make habtm resilient
against e
The implementation involves some funky regex's on the sql sent along to
the connection adapter, so I'm going to do some more extensive testing
within my own app before posting to Trac.
I like the idea, however perhaps it's not ambitious enough?
If instead of doing the value interpolation immed
I'm a bit hesitant to apply at patch that will break my own deployments.
Perhaps it should default to 0.0.0.0 and have the usage mention 'you
probably want to use 127.0.0.1?
On 5/26/06, Dee Zsombor <[EMAIL PROTECTED]> wrote:
Just a ping on this ticket
http://dev.rubyonrails.org/ticket/5133
Ad
committed. Thanks
On 5/17/06, Adam C. Greenfield <[EMAIL PROTECTED]> wrote:
Looking to draw attention to #4955
(http://dev.rubyonrails.org/ticket/4955), it is a small nil handling
patch. I included a unit test in the patch. If there is anything else
it needs (or if it should be changed in some
Not sure if rails-core is the best list to discuss this... Anyhow,
I'll take a look at the code and see if I see the problem.
It's probably not, but that's what config.after_initialize { } is for.
--
Cheers
Koz
___
Rails-core mailing list
Rails-cor
> As I see it, the reason to "hide" the internal api, from at least the main
> api documentation, is that there are far more people interested in working
> *with* Rails than there are people interested in working *on* Rails. For that
> 80 plus percent, having all the internal api docs mixed in with
> > I currently use RoR on a few small web sites, and some internal webapps,
> > but I spend 90% of my time with RoR with AR optimizing
> > it's speed.
Are you only noticing this speed problem with big batch operations
like you mentioned in the earlier email?
When working with an ORM, it's fairl
> Just created a ticket for:
>
> http://dev.rubyonrails.org/ticket/4673
>
> Which outlines the option to merge/diff or patch on upgrade.
>
> Currently I see the functionality of upgrading quite tedious, especially
> with the now planned rapid release cycle. This is solely due to the fact
> that I n
On 4/4/06, Pete Yandell <[EMAIL PROTECTED]> wrote:
> Let me sharpen up my first question, because I think it's essential
> no matter how you approach this:
>
> If I have a class that includes Reloadable, how can I declare a class
> variable (or equivalent thereof) that persists across reloads of th
> I have submitted a new patch file for
> http://dev.rubyonrails.org/ticket/4132 that no longer produces any
> conflicts or errors during the unit tests.
Applied
> This is supposed to combine :include's in a compatible fashion since
> they can either be an Array, Hash or a Symbol.
Shame that Obj
> The reason I created this patch is explained in the ticket and that I
> figured the :include route was a bit cleaner from a users perspective
> than a combo of :select and :joins.
The patch no longer applies cleanly, and seems to cause quite a few
failures (unless I've screwed up the merge). C
On 3/27/06, David Heinemeier Hansson <[EMAIL PROTECTED]> wrote:
> > So my question is... were my assumptions wrong (ie. my reasonings for
> > implementing :include) and will :include just not be supported and
> > should I just use the :select, :join combonation from this point?
>
> I understand the
Hey guys,
With the addition of has_many :through, a number of people will
probably want to add primary keys to their current 'rich association'
tables. Currently we don't have an add_primary_key. We have a ticket
for it[1], and I've attached a simple patch[2].
It works fine for mysql and postgre
Does the 'session' method do what you need?
http://rails.rubyonrails.org/classes/ActionController/SessionManagement/ClassMethods.html
On 3/24/06, Kyle Maxwell <[EMAIL PROTECTED]> wrote:
> Hi all,
> Rails tends to send the Set-cookie:_session_id... on every response,
> when session handling is e
> Please expand on this. How would this look? Often times you don't have
> an js option for something, so if we just expect you to an error would
> occur. Instead of now, where we just do a 406.
Also, we don't want to break existing apps where perhaps people are
always responding with XML irrespe
On 3/16/06, Michael Schoen <[EMAIL PROTECTED]> wrote:
> Michael Schoen wrote:
> > Michael Koziarski wrote:
> >> It doesn't explain why it works for me, but not for you though. What
> >> ruby version are you using, windows or unix? Anything els
> Hmm, now the tests fail for lack of #xmlschema.
irb(main):001:0> Time.now.xmlschema
NoMethodError: undefined method `xmlschema' for Wed Mar 15 20:37:38
NZDT 2006:Time
from (irb):1
irb(main):002:0> require 'time'
=> true
irb(main):003:0> Time.now.xmlschema
=> "2006-03-15T20:37:43+13:00"
worksforme.
What other components do you have checked out? I must have to move
something into activesupport?
On 3/15/06, Michael Schoen <[EMAIL PROTECTED]> wrote:
> Michael Koziarski wrote:
> >> Is there an easy way to rewrite the assertion so it works for folks not
>
> Is there an easy way to rewrite the assertion so it works for folks not
> in the Windy City?
I live in another windy city, so I noticed this too. I believe this
is now fixed as of [3870]. to_xml uses the xmlschema format (so
timezones are included) and the test now checks for the string in th
On 3/14/06, Michael Schoen <[EMAIL PROTECTED]> wrote:
> The changes to improve table aliasing in [3776] broke all sorts of
> associations for Oracle.
>
> The issue is that Oracle doesn't allow for table aliases using the AS
> keyword.
>
> ... LEFT OUTER JOIN authors AS authors ...
>
> is no
The tickets currently 'highlighted' for extra review by the core team
are in the following report:
http://dev.rubyonrails.org/report/19
If your favourite ticket isn't on that list, please add the
needs_review keyword so we can have a look. If one of the core team
removes the keyword, don't tak
On 3/13/06, Nicholas Seckar <[EMAIL PROTECTED]> wrote:
> See [3857]
>
> http://dev.rubyonrails.org/changeset/3857
Ah, yeah. Kevin Clark's refactoring of ActionPack's unit tests had
the same problem.
It really is strange behaviour ...
oh, and by the way, test:uncommitted? Nice!
--
Cheers
Koz
Hey guys,
I've had some reports of edge rails not working for windows when svn
isn't available in your path. Specifically, running rake migrate.
Does anyone have a windows installation around to test on?
--
Cheers
Koz
___
Rails-core mailing list
Ra
On 3/6/06, Rick Olson <[EMAIL PROTECTED]> wrote:
> So, I sat down to use set_fixture_class, and it bombed on the first
> thing I tried:
>
> set_fixture_class :content_drafts => "Article::Draft"
>
> I made a quick patch, and I'd appreciate a quick run through your
> tests to make sure it doesn't dis
> How can custom reader/writer methods be accomodated then ?
>
See
http://dev.rubyonrails.org/browser/trunk/activerecord/lib/active_record/base.rb#L1561
if you implement your own _before_type_cast methods you should be
fine. Why not just define a separate accessor though, i.e. one
used durin
On 3/6/06, Francois Beausoleil <[EMAIL PROTECTED]> wrote:
> Hi !
>
> Just wondering here, because if I define reader methods, then these
> aren't used in the forms.
>
> For example, I have this:
> class Customer
> def tax_rate
> (read_attribute(:tax_rate) * 100.0).to_i
> end
>
> def tax_r
> That is, setting a socket is the exception rather than the rule. For
> most of the get-up-and-running apps I've seen, the socket isn't
> necessary. Trying to set it is often an impediment to getting
> started with Rails. But I suspect there may be downsides that led to
> the decision to use a
On 3/2/06, Jon Tirsen <[EMAIL PROTECTED]> wrote:
> I'm working on the plugin for RBatis and a new little thing I'm toying
> around with called ActiveMessaging (sorry, David I stole the name from
> you from the TW AwayDay ;-)). Anyway, in both these applications I
> want to be able to have reloadabl
> Ok, found my problem, not sure if it's the same as yours -- locking
> wasn't returning true if the update was successful.
>
> Patch submitted:
>
> http://dev.rubyonrails.org/ticket/4015
>
And applied.
--
Cheers
Koz
___
Rails-core mailing lis
> We'd be happy to take on ActionWebServices, as we use it daily in
> much of our business process. I had run into the issues in 1.8.4
> but decided the benefits of AWS made 1.8.2 adequate for now. We
> were unaware there was a maintainer vacancy. The 'we' i'm referring
> to are myself, trey dem
> So you're saying "cool" isn't a benefit in itself. ;-)
>
>
> (But of course, I agree, if it's not backwards compatible it shouldn't be
> done.)
I agree too, and the change currently being proposed is backwards
compatible for exactly this reason.
David's rake -T concerns wouldn't be reason enou
> Is he alive? Does anyone know if he's OK?
Leon's fine. He's just overworked at the dayjob.
> I agree that for something to be in core it must be maintainable by
> known maintainers. I assume Leon fell into that category, without (I
> guess) being in the core team.
Leon was in the core team, i
Hey guys,
We're now beginning to finalise rails 1.1, and we need to make sure
that we don't miss any heinous bugs. While we'll all be giving the
list a once over, we're only human and we're likely to miss things.
So, if you have any tickets which you think need to be addressed,
please bring them
> form_for : comment, comment, :action => 'update' do; end
> =>
>
> ...hence why I was asking what you wanted to do with it. I think it
> needs to be reverted to the old API.
I can see that it's broken, but why do you think it needs to be reverted?
> http://dev.rubyonrails.org/browser/trunk
> Thanks everyone...
No, thank you. This is a great addition.
--
Cheers
Koz
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Hey guys,
If you make extensive use of eager loaded associations in your
application, and run on edge, we could really use your help testing a
very nice, but quite intrusive patch that's been submitted.
http://dev.rubyonrails.org/ticket/3913
It's a nice refactoring of the code, and a great new
On 2/20/06, Kyle Maxwell <[EMAIL PROTECTED]> wrote:
> What if, instead of a simple integer sequence, migrations used timestamps?
Could we do that in a backwards compatible way? The problem of local,
uncommited migrations isn't something that's worth breaking backwards
compatibility
--
Cheers
Koz
> I know that supporting composite keys is not a MUST, but it's a SHOULD.
Your invoice lines will have an invoice_id relating them to the
invoice, it doesn't get much more related than that. If you're
seeing the ids as anything other than serialised object-identity, then
you're over using.
The
> 1. I tend to think URL as a part of the user interface. If the user
> look at (usually simple and structured in rails application) URL,
> wouldn't she be confused by the seemingly random and very large
> number assigned to her reply post? Topic's id #87 corresponds to the
> 87th-ness nature of
On 2/18/06, Dae San Hwang <[EMAIL PROTECTED]> wrote:
> Hi,
>
> As I understand, composite primary keys aren't supported in
> ActiveRecord yet. May I ask if there are plans for this feature?
> Better yet, if this feature is under development, how's the progress
> going?
There is currently no work
> After trying various options (such as cut-and-paste and refactoring),
> I reluctantly concluded that the simplest way to achieve my goal
> would be to simply replace the SQL portions of ActiveRecord with a
> more general "query" mechanism:
Hey Ernie,
The main problem with a large scale refactor
> Is there a problem with me cleaning out duplicate tickets and such? Koz
> mentioned using XPATCH
>
> for non-trivial patches without tests. I've also been going through patches
> which I find to be a welcome > addition and testing them against trunk and
> adding
> a tested tag to them or adding
> One idea might be to have any helper method to have a wrapper around it,
> which is cleaned after using the <%= method. Such an example,
>
> Such as link_to(:controller => 'xss', :action => 'safe') in it's raw state
> appends and prepends the {{SAFE}} and {{/SAFE}} string, which it's contents
> a
On 2/12/06, Nathaniel S. H. Brown <[EMAIL PROTECTED]> wrote:
> As I said before, I (or we, for whoever is in support) can solve the minor
> details, and provide solutions with a little bit of creativity. I am of the
> opinion that if you see points such as the ones you mentioned, you may also
> be
On 2/12/06, Nathaniel S. H. Brown <[EMAIL PROTECTED]> wrote:
> All of those helper functions would obviously need to be changed so that
> they work with the default <%=h methods. The <%= tag could be smart enough
> to realize what it is parsing, and if it's a helper method, to skip it.
>
> It's an
On 2/12/06, Nathaniel S. H. Brown <[EMAIL PROTECTED]> wrote:
> I was just reading a blog post, about how PHP applications lack so much as
> far as security goes, and it got me thinking that Rails should come default
> secure, and you should have to force it to be less secure.
>
> On that note, I ca
> While you're giving thought to that, what are your thoughts on renaming the
> quote method inside of AR:B? Quite a few tickets come through for that as
> well.
Unfortunately we have a lot of people calling the quote method from
plugins, custom code etc. We can't rename it without breaking
backw
> They all have to do with the Date Helper.
>
> * Support index and/or @auto_index
> * Enable discard year
> * time_select (alias to datetime_select with previous patch applied)
> * Unique id's as per w3c spec
> * :order for datetime_select to mimic date_select :order option
> * add :include_second
t; > > >
> > > > 3 transaction tests failing:
> > > >
> > > > 20) Failure:
> > > > test_callback_rollback_in_save(TransactionTest) [./test/
> > > > transactions_test.rb:119]:
> > > > is not true.
> > > >
> > &g
> Yep, I have the dbs set up right, MySQL 5.1.0 with InnoDB enabled on a fresh
> SuSE 10 box. Most of the tests pass, I'll tinker with it and see what's
> happening.
>
> Curious if anyone on the core team tests outside of OSX? (Meaning, are the
> tests known to pass in a non-osx environment?) The r
On 2/10/06, Bob Silva <[EMAIL PROTECTED]> wrote:
>
>
>
> I know this is probably a dumb question, but should all the AR unit tests be
> succeeding for mysql?
They're passing to me, have you run the two drop and recreate scripts
in /test/fixtures/db_definitions?
> Just curious if mysql is designe
On 2/10/06, Kevin Clark <[EMAIL PROTECTED]> wrote:
> I'll give it a shot. Is there a reason we can't load up the individual
> schema to a db and use schema dumper? Clean up if needed?
> Kev
It's also about making sure that the rake test_x loads the schema, and
runs the tests.
But I think you've j
On 2/7/06, Michael Schoen <[EMAIL PROTECTED]> wrote:
> Got a handful of pending patches, most of them small tweaks to the
> Oracle adapter. Should be quick work for somebody.
>
>http://dev.rubyonrails.org/ticket/2446
>http://dev.rubyonrails.org/ticket/3210
>http://dev.rubyonrails.org/ti
> Talking to yourself, first sign of madness and all that, but instead
> of hastests I propose 'tested', to indicate that the patch has unit
> tests, and that those tests have been run. There's no reason
> submitters shouldn't add this keyword themselves, if they wish.
Tested sounds like a great
> Rails is completely opensourced under the MIT license as far as I
> know. There shouldn't be proprietary tests. Testing against
> applications is good, but really, that is what unit testing is used
> for in the codebase.
Amen.
> Merge monkeys isn't necesarily the best course of action though. D
> Which would include giving the "monkeys" complete access to the 37s
> application code (because I think THIS is what all the patches get
> tested against, I think). The problem is that there are tests which
> are not included in Rails and are effectively proprietary, but 37s
> (being the core mai
> I've seen this and some other weird error in another project too. I'm
> sure it'll get sorted out this weekend. Ulysses wasn't seeing any
> errors, and I'm seeing two different errors in two apps. Very
> strange.
I can reproduce this, I'll take a look into it. But I think it's
something Ni
On 1/28/06, Kevin Clark <[EMAIL PROTECTED]> wrote:
> I've got a patch ready adding the pagination tests (and confirming the
> bug with :include). It depends on ticket 3606
> (http://dev.rubyonrails.org/ticket/3606) so I'll submit it as soon as
> 3606 is checked in.
> Kev
As the original author, Sa
On 1/29/06, John W. Long <[EMAIL PROTECTED]> wrote:
> I wonder if something like this would make a good addition to the core:
>
> http://wiseheartdesign.com/articles/2006/01/28/test-helpers-for-rails
>
> It seems a useful and helpful convention.
Hi John,
I seem to remember seeing a PATCH ticket t
> Yet only now I'm upgrading some rails 0.13.1 apps.
Man, that's *so* out of dat.e ;)
> Just going by the changelogs I see a lot of stuff/fixes I was hoping
> for. AR failed a few tests though, so I got a bit concerned. But I
> guess I'll give it a go.
All the tests should be working just fine a
> I have cleaned those now. I used Watir to visit the Edit screen for
> every page, check the content for spam, and remove it if present.
If you can give us some regular expressions that you used with watir,
we may be able to protect the wiki with mod_security. This will at
least save us some g
> I agree that redirect_to :back shouldn't be removed. Backwards
> compatability is good. I just really think the only responsible thing
> to do without going any further into logic that shouldn't be in the
> core is to throw an exception when there is a problem.
>
> Is it really that big of a prob
> I agree. Is it possible, David, that you kind of regret having put
> it in there? The way you talk about it sounds like that's the case.
The flip side of this, is that if we remove it, we break existing
applications because on the off chance that an infinite redirect may
occur.
Also, there
On 1/8/06, Duane Johnson <[EMAIL PROTECTED]> wrote:
> Here's a gentle nudge for ticket #1911 (more flexible fixtures). Can
> we get this integrated soon?
Hi Duane,
This is a fairly major change to the current fixtures system. It
introduces some complicated error conditions (overlapping fixture
> foo:
> id: 1
> created_at: <%= 5.days.ago.to_s(:db) %>
>
This definitely works, and we use it throughout the strongspace
fixtures. But ... yuck.
Yaml has a format for dates and times, and I think we should support
it if possible. Kevin, would you be able to look into a patch which
fix
> Has this deprecation you speak of been written up anywhere or just
> your opinion? Just curious.
Components haven't been formally or informally deprecated. However
they're not very widely used. The .14 release had a memory leak in
components which didn't get noticed for a few weeks.
--
Chee
> So how to place true and false (1 and 0, 't' and 'f' etc) or
> Date values or what have you.
>
> Does anyone have suggestions/comments to that end?
For boolean values, you can just use true/false. The adapters know
how to quote the values correctly. AR's own unit tests rely on this
behaviour.
> Is this happening for a reason? It seems to me that Rails should be
> a little more robust on its "minimum requirements" for a basic
> controller and view to work properly. I'd like to investigate
> further, so I'm looking for a little feedback first.
>
> Duane Johnson
> (canadaduane)
> http://
On 12/31/05, Abdur-Rahman Advany <[EMAIL PROTECTED]> wrote:
> Generating code is something I have never liked. Its good for basic
> setup but hard to maintain. One of the benefits of components is that it
> would be easy to update them...
Conversely, generated code is easy to modify.
The assumpti
> Simply put, a _character_ is no longer _one byte long_ when you get
> beyond the characters you can see printed on your keyboard. Even
> simple punctuation like these "double quotation marks" take up
> _two bytes_ each, and stuff like ⾦ is _three bytes_ in UTF-8.
The problem with UTF-8 is that t
This is really nice Rick.
>
omg wtf, That's not semantic!!! What I'm trying to get at is that
customisable markup may be a good idea. Though it also sounds like a
pain in the ass. After triaging all those Inflector tickets, I'm
terrified of anything which smells like a ticket storm ;)
> Ha
On 12/14/05, Francois Paul <[EMAIL PROTECTED]> wrote:
> seams Rails 0.1.0 has been released? I was expecting a big todo? did i
> miss a release anouncement or something?
We have a new webpage, is that enough? ;)
http://www.rubyonrails.com/
--
Cheers
Koz
___
1 - 100 of 108 matches
Mail list logo
