Namespace conflict.
Dave Howell
I'm also using the helper BlueForm. It turns out that BlueForm has defined a 'Form' class as well, which also has a .select method. This has made it rather difficult to build an HTML form that contains a list of product forms.
I could rename the Sequel reference, but I really don't want to. I use the db tables way way more than I use BlueForm. Is there a way to keep helpers from cluttering up the main namespace?
Michael Fellinger
http://github.com/Ramaze/ramaze/blob/master/lib/ramaze/helper/blue_form.rb
If you look at this, you will see that Form is under the BlueForm module.
BlueForm is included into your Controller when you use the helper
method, which puts Form into the namespace of your Controller, but
that's still not anywhere close to the main namespace. If you want to
reference your own Form, use the proper name, depending on where you
put it that might be something like ::Form or YourModule::Form.
--
Michael Fellinger
CTO, The Rubyists, LLC
Dave Howell
On Jul 15, 2010, at 17:47 , Michael Fellinger wrote:
> http://github.com/Ramaze/ramaze/blob/master/lib/ramaze/helper/blue_form.rb
> If you look at this, you will see that Form is under the BlueForm module.
> BlueForm is included into your Controller when you use the helper
> method, which puts Form into the namespace of your Controller, but
> that's still not anywhere close to the main namespace.
I concede that 'main namespace' was not the correct term. However, since everything I do is within the context of a controller, it is effectively ubiquitous, no matter how far from the main namespace I happen to be.
> If you want to
> reference your own Form, use the proper name, depending on where you
> put it that might be something like ::Form or YourModule::Form.
"My own Form" is Sequel's Form. My current workaround is to reference it as DB[:lstforms], but I lose a little bit of functionality doing that, and it makes that one table reference completely different from all my other table references.
On the other hand, I *never* reference BlueForm's "Form" class directly. I'm not entirely sure why, but I'm only using it like
form(:method => :post, :action=>"save") do |f|
blah blah blah
end
I would *much,* *much* prefer to kick BlueForm's clutter out of my Controller's name space, and make IT be the thing that requires BlueForm::Form or whatever modularized reference would be required, to the degree that, if there isn't another way, I"ll just go through the entire BlueForm library and hard-code every class to have "BlueForm" in front of its current name.
In general, I really like the standard Ruby approach that nothing except the canonical core commands get to climb out of their own namespace unless I deliberately invite them with 'include.' Unexpected name collisions is one good reason why. If it's not possible to invoke a helper without including everything in it in the controller's namespace, well, that kind of help I can do without.
Dave Howell
------------------------------------------------------------ CGI::escape
CGI::escape(str)
------------------------------------------------------------------------
escape url encode
>> someURL = CGI::escape(database_stuff)
=> undefined method `escape' for Innate::Helper::CGI:Module
{sigh} Another unexpected namespace conflict? If this CGI module has decided to take the same name as the standard Ruby CGI class, why doesn't it at least include the former's functionality?
Pistos
> >> someURL = CGI::escape(database_stuff)
> => undefined method `escape' for Innate::Helper::CGI:Module
>
> {sigh} Another unexpected namespace conflict? If this CGI module has decided to take the same name as the standard Ruby CGI class, why doesn't it at least include the former's functionality?
stdlib class as ::CGI within Ramaze applications.
See here for uninclusion strategies:
http://stackoverflow.com/questions/2403057/how-can-i-reverse-rubys-include-function
Pistos
Michael Fellinger
Dave Howell
On Jul 20, 2010, at 16:32 , Pistos wrote:
> Honestly, the standard, accepted practice is to refer to the Ruby
> stdlib class as ::CGI within Ramaze applications.
Er, OK. How would one go about learning such standard accepted practices for building things with Ramaze?
Lars Olsson
only thing guaranteed to work is to use the complete 'path' to a
class. For instance:
module Foo
class Useful
end
end
module Bar
class Useful
end
end
include Foo
include Bar
x = Useful.new # Which class is this?
In this situation, it can be pretty hard to know beforehand which of
the Useful classes that x is an instance of. However, if you add the
module name (namespace), things become much clearer:
x = Foo::Useful
Whenever using classes that might exist in more than one module,
adding the module name is the easiest way to distinguish things. This
is true for regular includes as well as Ramazes helpers.
Finally, the ::Useful syntax is a special case, meaning that the
Useful class is not a part of any "regular" module but instead is
defined in the "anonymous top level" module. Like this:
class Useful
end
module Foo
class Useful
end
class Silly
def initialize()
x = Useful.new # class is Foo::Useful
y = Foo::Useful.new # class is Foo::Useful
z = ::Useful.new # class is (anonymous top level module)::Useful
end
end
end
/lasso
Dave Howell
On Jul 22, 2010, at 1:01 , Lars Olsson wrote:
> Clashing namespaces is not a problem unique to Ramaze. In ruby, the
> only thing guaranteed to work is to use the complete 'path' to a
> class. For instance:
>
> module Foo
> class Useful
> end
> end
>
> module Bar
> class Useful
> end
> end
>
> include Foo
> include Bar
Yes, I know; that was the entire point of my original post.
I try not to 'include' something unless I know what methods it has. But Ramaze's helpers include themselves automatically whether I approve of that or not.
helper :bluecloth
results in BlueCloth being >>included,<< not merely accessible. I am not given the option of referring to it by the complete path.
Lars Olsson
--------------------------------------------
Innate::HelperAccess#helper
helper(*helpers)
From gem innate-2010.07
------------------------------------------------------------------------
Convenience method used by Innate::Node.
Usage:
class Hi
extend Innate::HelperAccess
helper :cgi, :link, :aspect
end
This will require the helpers and call:
Hi.include(Innate::Helper::CGI)
Hi.include(Innate::Helper::Link)
Hi.include(Innate::Helper::Aspect)
In other words, the helper method does two things. First it requires
the file and then it includes the helper class in your current class
(the controller). If you don't want the helpers methods included in
your class, don't use the helper method, just require the file.
require 'ramaze/helper/blue_form'
and then you should be able to reference stuff in blue_form with
Ramaze::Helper::BlueForm.whatever
Is this what you want to do?
/lasso
>
> - Visa citerad text -
Dave Howell
> In other words, the helper method does two things. First it requires
> the file and then it includes the helper class in your current class
> (the controller). If you don't want the helpers methods included in
> your class, don't use the helper method, just require the file.
>
> require 'ramaze/helper/blue_form'
>
> and then you should be able to reference stuff in blue_form with
>
> Ramaze::Helper::BlueForm.whatever
>
> Is this what you want to do?
That's exactly what I want to do. Thanks!