Original announcement at http://blog.inquirylabs.com/ [1] == What is bundled_resource? = If your development is in any way similar to mine, there are a number of useful resources out there that make web applications shine beautifully. For example, there?s the Dynarch calendar and the textarea tools. There are a number of others?too many, in fact. The problem is that as a web developer, it sometimes takes some real surgery to put each one of these in to an application. And then when you create a new page that uses these resources (even within the same app), you have to figure out which pieces to cut and paste to get it functional. Take the Dynarch calendar, for instance. There are 4 javascript files, 1 CSS file (among several to choose from), 2 images, several helper methods, and a controller method that you?ll need in order to get it to work with Rails. Sometimes it?s easier just to ignore the calendar bit because it?s such a pain to set up. The bundled_resource plugin makes it trivially easy to keep all of these pieces together, and to include each "bundle" with a single method, require_bundle, wherever the bundle is needed. == Examples = <%= require_bundle :dynarch_calendar, :color => ''green'', :language => ''en'', :icon => ''/images/my_calendar.gif'' %> <%= dynarch_date_select ''user'', ''birthday'' %> <%= dynarch_datetime_select ''user'', ''lunch_meeting'' %> == What''s new in v. 0.9? = This release marks a much improved and nearly completely rewritten dynarch calendar bundle. Here?s what?s new: It is no longer necessary to call convert_date_to_multi_params! in your controller Backwards compatibility for non-javascript browsers is now improved. Calling dynarch_date_select will call the built-in rails date_select method so that users whose browsers have no javascript can still select a date in a reasonable way. There is no longer an obnoxious ?:date? field in the returned multiparameter values. Bundles now accept optional parameters. For the dynarch_calendar bundle, you can specify the color stylesheet, language and icon for your dynarch calendar. 12-hour time is handled in a novel way, so that the user enters a 12- hour time (e.g. 3 PM) and Rails can read it as if it?s a 24-hour time. Better documentation. Version 0.9 of bundled_resource now also includes a ?stateful_form? bundle that makes it easier to store the open/closed states of form sections. This is particularly useful for AJAX forms that have hidden sections that the user can open up. When the form is submitted to the server and returned with an error, the form will retain its open/ closed states so that it?s just as the user expects it. == Download and Subversion = TAR / GZIP: http://inquirylabs.com/downloads/bundled_resource-0.9.tgz Subversion: svn://syncid.textdriven.com/svn/opensource/ bundled_resource/trunk [1] The permalink is http://blog.inquirylabs.com/2006/01/26/bundled- resource-v-09-full-dynarch-calendar-support/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060127/a3b336a1/attachment-0001.html
Duane Johnson wrote:> Original announcement at http://blog.inquirylabs.com/ [1] > > == What is bundled_resource? => > If your development is in any way similar to mine, there are a number of > useful resources out there that make web applications shine beautifully. > For example, there?s the Dynarch calendar > <http://www.dynarch.com/projects/calendar/> and the textarea tools > <http://livsey.org/experiments/textareatools/>. There are a number of > others?too many, in fact.Cool, nice work. I really need to rewrite textarea tools at some point as the code could be a hell of a lot nicer. Hadn''t realised quite how popular they would be. about 75% of the traffic to my site comes in from links to it! -- R.Livsey http://livsey.org
On Jan 27, 2006, at 5:09 AM, Richard Livsey wrote:> Duane Johnson wrote: >> Original announcement at http://blog.inquirylabs.com/ [1] >> == What is bundled_resource? =>> If your development is in any way similar to mine, there are a >> number of useful resources out there that make web applications >> shine beautifully. For example, there?s the Dynarch calendar >> <http://www.dynarch.com/projects/calendar/> and the textarea tools >> <http://livsey.org/experiments/textareatools/>. There are a number >> of others?too many, in fact. > > Cool, nice work. > > I really need to rewrite textarea tools at some point as the code > could be a hell of a lot nicer. Hadn''t realised quite how popular > they would be. about 75% of the traffic to my site comes in from > links to it! >Ahh, so you''re the guy :) Thanks so much for making those tools available--it''s so nice to have a drop-in behavioral modification to text areas. As you''ve mentioned, there is a little more work to do--especially with Firefox 1.5. For example, when I click on one of the 4 text area icons, I see a dotted box (meaning "active link") going from the upper-left corner of the browser window to the lower-right corner of the icon that was clicked. Possibly a firefox bug, but it seemed to work ok in earlier releases. Weird, eh? Thanks again, and good luck with any changes / refactors :) Duane Johnson (canadaduane) http://blog.inquirylabs.com/
Duane-- I''m using the login_engine and it works just fine until I install the bundled resource plugin. Evidently, Rails loads bundled resource first (alphabetical order?), which does a require on ''application_helper''. My application_helper, of course, includes login_engine which has not yet been loaded. So, the whole thing spits up. Is there a known way to affect the load order to work around this? Thanks, Steve Ross Duane Johnson wrote:> Original announcement at http://blog.inquirylabs.com/ [1] > > == What is bundled_resource? => > If your development is in any way similar to mine, there are a number > of useful resources out there that make web applications shine > beautifully. For example, there?s the Dynarch calendar and the > textarea tools. There are a number of others?too many, in fact. The > problem is that as a web developer, it sometimes takes some real > surgery to put each one of these in to an application. And then when > you create a new page that uses these resources (even within the same > app), you have to figure out which pieces to cut and paste to get it > functional. Take the Dynarch calendar, for instance. There are 4 > javascript files, 1 CSS file (among several to choose from), 2 > images, several helper methods, and a controller method that you?ll > need in order to get it to work with Rails. Sometimes it?s easier > just to ignore the calendar bit because it?s such a pain to set up. > > The bundled_resource plugin makes it trivially easy to keep all of > these pieces together, and to include each "bundle" with a single > method, require_bundle, wherever the bundle is needed. > > == Examples => > <%= require_bundle :dynarch_calendar, > :color => ''green'', > :language => ''en'', > :icon => ''/images/my_calendar.gif'' %> > > <%= dynarch_date_select ''user'', ''birthday'' %> > > <%= dynarch_datetime_select ''user'', ''lunch_meeting'' %> > > == What''s new in v. 0.9? => > This release marks a much improved and nearly completely rewritten > dynarch calendar bundle. > > Here?s what?s new: > > It is no longer necessary to call convert_date_to_multi_params! in > your controller > Backwards compatibility for non-javascript browsers is now improved. > Calling dynarch_date_select will call the built-in rails date_select > method so that users whose browsers have no javascript can still > select a date in a reasonable way. > There is no longer an obnoxious ?:date? field in the returned > multiparameter values. > Bundles now accept optional parameters. For the dynarch_calendar > bundle, you can specify the color stylesheet, language and icon for > your dynarch calendar. > 12-hour time is handled in a novel way, so that the user enters a 12- > hour time (e.g. 3 PM) and Rails can read it as if it?s a 24-hour time. > Better documentation. > Version 0.9 of bundled_resource now also includes a ?stateful_form? > bundle that makes it easier to store the open/closed states of form > sections. This is particularly useful for AJAX forms that have hidden > sections that the user can open up. When the form is submitted to the > server and returned with an error, the form will retain its open/ > closed states so that it?s just as the user expects it. > > == Download and Subversion => > TAR / GZIP: http://inquirylabs.com/downloads/bundled_resource-0.9.tgz > Subversion: svn://syncid.textdriven.com/svn/opensource/ > bundled_resource/trunk > > > [1] The permalink is http://blog.inquirylabs.com/2006/01/26/bundled- > resource-v-09-full-dynarch-calendar-support/-- Posted via http://www.ruby-forum.com/.
I''ve improved the technique a bit so that this conflict no longer occurs. The changes are in subversion: svn://syncid.textdriven.com/svn/opensource/bundled_resource/trunk Hopefully this will make life easier! Duane On Jan 30, 2006, at 4:00 PM, Steve Ross wrote:> Duane-- > > I''m using the login_engine and it works just fine until I install the > bundled resource plugin. Evidently, Rails loads bundled resource first > (alphabetical order?), which does a require on ''application_helper''. > > My application_helper, of course, includes login_engine which has not > yet been loaded. So, the whole thing spits up. > > Is there a known way to affect the load order to work around this? > > Thanks, > > Steve Ross > > > Duane Johnson wrote: >> Original announcement at http://blog.inquirylabs.com/ [1] >> >> == What is bundled_resource? =>> >> If your development is in any way similar to mine, there are a number >> of useful resources out there that make web applications shine >> beautifully. For example, there?s the Dynarch calendar and the >> textarea tools. There are a number of others?too many, in fact. The >> problem is that as a web developer, it sometimes takes some real >> surgery to put each one of these in to an application. And then when >> you create a new page that uses these resources (even within the same >> app), you have to figure out which pieces to cut and paste to get it >> functional. Take the Dynarch calendar, for instance. There are 4 >> javascript files, 1 CSS file (among several to choose from), 2 >> images, several helper methods, and a controller method that you?ll >> need in order to get it to work with Rails. Sometimes it?s easier >> just to ignore the calendar bit because it?s such a pain to set up. >> >> The bundled_resource plugin makes it trivially easy to keep all of >> these pieces together, and to include each "bundle" with a single >> method, require_bundle, wherever the bundle is needed. >> >> == Examples =>> >> <%= require_bundle :dynarch_calendar, >> :color => ''green'', >> :language => ''en'', >> :icon => ''/images/my_calendar.gif'' %> >> >> <%= dynarch_date_select ''user'', ''birthday'' %> >> >> <%= dynarch_datetime_select ''user'', ''lunch_meeting'' %> >> >> == What''s new in v. 0.9? =>> >> This release marks a much improved and nearly completely rewritten >> dynarch calendar bundle. >> >> Here?s what?s new: >> >> It is no longer necessary to call convert_date_to_multi_params! in >> your controller >> Backwards compatibility for non-javascript browsers is now improved. >> Calling dynarch_date_select will call the built-in rails date_select >> method so that users whose browsers have no javascript can still >> select a date in a reasonable way. >> There is no longer an obnoxious ?:date? field in the returned >> multiparameter values. >> Bundles now accept optional parameters. For the dynarch_calendar >> bundle, you can specify the color stylesheet, language and icon for >> your dynarch calendar. >> 12-hour time is handled in a novel way, so that the user enters a 12- >> hour time (e.g. 3 PM) and Rails can read it as if it?s a 24-hour >> time. >> Better documentation. >> Version 0.9 of bundled_resource now also includes a ?stateful_form? >> bundle that makes it easier to store the open/closed states of form >> sections. This is particularly useful for AJAX forms that have hidden >> sections that the user can open up. When the form is submitted to the >> server and returned with an error, the form will retain its open/ >> closed states so that it?s just as the user expects it. >> >> == Download and Subversion =>> >> TAR / GZIP: http://inquirylabs.com/downloads/ >> bundled_resource-0.9.tgz >> Subversion: svn://syncid.textdriven.com/svn/opensource/ >> bundled_resource/trunk >> >> >> [1] The permalink is http://blog.inquirylabs.com/2006/01/26/bundled- >> resource-v-09-full-dynarch-calendar-support/ > > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Hello guys, I''m having trouble with bundled_resource plugin, trying to get a dynarch_date_select going... I''ve got the following in my layout file: <head> <title>ABC123</title> <%= stylesheet_auto_link_tags %> <%= stylesheet_auto_include_tags %> ... </head> ... In my view (actually it''s a _form.rhtml), <%= error_messages_for ''...'' %> <% require_bundle :dynarch_calendar %> ... <%= dynarch_date_select "tablename", "fieldname" %> When I render this in Firefox, I see something identical to what I would see if I was using good old date_select. ''View source'' shows me a bunch of drop down boxes, identical to what I''d see from date_select. In the log file, I can see a bunch of dynarch_calendar .jss files all being loaded successfully (i.e. they''re returning 200s). I''m fairly sure I must''ve missed out a step, but I can''t find it in the documentation anywhere. Can anybody help? Thanks in advance Dave M. On 02/02/06, Duane Johnson <duane.johnson@gmail.com> wrote:> I''ve improved the technique a bit so that this conflict no longer > occurs. The changes are in subversion: > > svn://syncid.textdriven.com/svn/opensource/bundled_resource/trunk > > Hopefully this will make life easier! > Duane > > On Jan 30, 2006, at 4:00 PM, Steve Ross wrote: > > > Duane-- > > > > I''m using the login_engine and it works just fine until I install the > > bundled resource plugin. Evidently, Rails loads bundled resource first > > (alphabetical order?), which does a require on ''application_helper''. > > > > My application_helper, of course, includes login_engine which has not > > yet been loaded. So, the whole thing spits up. > > > > Is there a known way to affect the load order to work around this? > > > > Thanks, > > > > Steve Ross > > > > > > Duane Johnson wrote: > >> Original announcement at http://blog.inquirylabs.com/ [1] > >> > >> == What is bundled_resource? => >> > >> If your development is in any way similar to mine, there are a number > >> of useful resources out there that make web applications shine > >> beautifully. For example, there''s the Dynarch calendar and the > >> textarea tools. There are a number of others?too many, in fact. The > >> problem is that as a web developer, it sometimes takes some real > >> surgery to put each one of these in to an application. And then when > >> you create a new page that uses these resources (even within the same > >> app), you have to figure out which pieces to cut and paste to get it > >> functional. Take the Dynarch calendar, for instance. There are 4 > >> javascript files, 1 CSS file (among several to choose from), 2 > >> images, several helper methods, and a controller method that you''ll > >> need in order to get it to work with Rails. Sometimes it''s easier > >> just to ignore the calendar bit because it''s such a pain to set up. > >> > >> The bundled_resource plugin makes it trivially easy to keep all of > >> these pieces together, and to include each "bundle" with a single > >> method, require_bundle, wherever the bundle is needed. > >> > >> == Examples => >> > >> <%= require_bundle :dynarch_calendar, > >> :color => ''green'', > >> :language => ''en'', > >> :icon => ''/images/my_calendar.gif'' %> > >> > >> <%= dynarch_date_select ''user'', ''birthday'' %> > >> > >> <%= dynarch_datetime_select ''user'', ''lunch_meeting'' %> > >> > >> == What''s new in v. 0.9? => >> > >> This release marks a much improved and nearly completely rewritten > >> dynarch calendar bundle. > >> > >> Here''s what''s new: > >> > >> It is no longer necessary to call convert_date_to_multi_params! in > >> your controller > >> Backwards compatibility for non-javascript browsers is now improved. > >> Calling dynarch_date_select will call the built-in rails date_select > >> method so that users whose browsers have no javascript can still > >> select a date in a reasonable way. > >> There is no longer an obnoxious ":date" field in the returned > >> multiparameter values. > >> Bundles now accept optional parameters. For the dynarch_calendar > >> bundle, you can specify the color stylesheet, language and icon for > >> your dynarch calendar. > >> 12-hour time is handled in a novel way, so that the user enters a 12- > >> hour time (e.g. 3 PM) and Rails can read it as if it''s a 24-hour > >> time. > >> Better documentation. > >> Version 0.9 of bundled_resource now also includes a "stateful_form" > >> bundle that makes it easier to store the open/closed states of form > >> sections. This is particularly useful for AJAX forms that have hidden > >> sections that the user can open up. When the form is submitted to the > >> server and returned with an error, the form will retain its open/ > >> closed states so that it''s just as the user expects it. > >> > >> == Download and Subversion => >> > >> TAR / GZIP: http://inquirylabs.com/downloads/ > >> bundled_resource-0.9.tgz > >> Subversion: svn://syncid.textdriven.com/svn/opensource/ > >> bundled_resource/trunk > >> > >> > >> [1] The permalink is http://blog.inquirylabs.com/2006/01/26/bundled- > >> resource-v-09-full-dynarch-calendar-support/ > > > > > > -- > > Posted via http://www.ruby-forum.com/. > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Hi David, The dynarch_date_select renders the normal rails date_select at first, and then adds a little javascript right after it to convert it to a dynarch calendar. This is mostly for backwards compatibility so that browsers without JS enabled can still select a date. So that would (hopefully) explain the origin of your situation... however, why it''s not converting to a dynarch calendar as it should, I''m not sure... have you checked the Javascript Console to see if you''re getting any errors? Duane Johnson (canadaduane) http://blog.inquirylabs.com/ On Feb 27, 2006, at 8:26 PM, David Mitchell wrote:> Hello guys, > > I''m having trouble with bundled_resource plugin, trying to get a > dynarch_date_select going... > > I''ve got the following in my layout file: > <head> > <title>ABC123</title> > <%= stylesheet_auto_link_tags %> > <%= stylesheet_auto_include_tags %> > ... > </head> > ... > > In my view (actually it''s a _form.rhtml), > <%= error_messages_for ''...'' %> > <% require_bundle :dynarch_calendar %> > ... > <%= dynarch_date_select "tablename", "fieldname" %> > > When I render this in Firefox, I see something identical to what I > would see if I was using good old date_select. ''View source'' shows me > a bunch of drop down boxes, identical to what I''d see from > date_select. > > In the log file, I can see a bunch of dynarch_calendar .jss files all > being loaded successfully (i.e. they''re returning 200s). > > I''m fairly sure I must''ve missed out a step, but I can''t find it in > the documentation anywhere. > > Can anybody help? > > Thanks in advance > > Dave M. > > > > > > On 02/02/06, Duane Johnson <duane.johnson@gmail.com> wrote: >> I''ve improved the technique a bit so that this conflict no longer >> occurs. The changes are in subversion: >> >> svn://syncid.textdriven.com/svn/opensource/bundled_resource/trunk >> >> Hopefully this will make life easier! >> Duane >> >> On Jan 30, 2006, at 4:00 PM, Steve Ross wrote: >> >>> Duane-- >>> >>> I''m using the login_engine and it works just fine until I install >>> the >>> bundled resource plugin. Evidently, Rails loads bundled resource >>> first >>> (alphabetical order?), which does a require on ''application_helper''. >>> >>> My application_helper, of course, includes login_engine which has >>> not >>> yet been loaded. So, the whole thing spits up. >>> >>> Is there a known way to affect the load order to work around this? >>> >>> Thanks, >>> >>> Steve Ross >>> >>> >>> Duane Johnson wrote: >>>> Original announcement at http://blog.inquirylabs.com/ [1] >>>> >>>> == What is bundled_resource? =>>>> >>>> If your development is in any way similar to mine, there are a >>>> number >>>> of useful resources out there that make web applications shine >>>> beautifully. For example, there''s the Dynarch calendar and the >>>> textarea tools. There are a number of others?too many, in fact. The >>>> problem is that as a web developer, it sometimes takes some real >>>> surgery to put each one of these in to an application. And then >>>> when >>>> you create a new page that uses these resources (even within the >>>> same >>>> app), you have to figure out which pieces to cut and paste to >>>> get it >>>> functional. Take the Dynarch calendar, for instance. There are 4 >>>> javascript files, 1 CSS file (among several to choose from), 2 >>>> images, several helper methods, and a controller method that you''ll >>>> need in order to get it to work with Rails. Sometimes it''s easier >>>> just to ignore the calendar bit because it''s such a pain to set up. >>>> >>>> The bundled_resource plugin makes it trivially easy to keep all of >>>> these pieces together, and to include each "bundle" with a single >>>> method, require_bundle, wherever the bundle is needed. >>>> >>>> == Examples =>>>> >>>> <%= require_bundle :dynarch_calendar, >>>> :color => ''green'', >>>> :language => ''en'', >>>> :icon => ''/images/my_calendar.gif'' %> >>>> >>>> <%= dynarch_date_select ''user'', ''birthday'' %> >>>> >>>> <%= dynarch_datetime_select ''user'', ''lunch_meeting'' %> >>>> >>>> == What''s new in v. 0.9? =>>>> >>>> This release marks a much improved and nearly completely rewritten >>>> dynarch calendar bundle. >>>> >>>> Here''s what''s new: >>>> >>>> It is no longer necessary to call convert_date_to_multi_params! in >>>> your controller >>>> Backwards compatibility for non-javascript browsers is now >>>> improved. >>>> Calling dynarch_date_select will call the built-in rails >>>> date_select >>>> method so that users whose browsers have no javascript can still >>>> select a date in a reasonable way. >>>> There is no longer an obnoxious ":date" field in the returned >>>> multiparameter values. >>>> Bundles now accept optional parameters. For the dynarch_calendar >>>> bundle, you can specify the color stylesheet, language and icon for >>>> your dynarch calendar. >>>> 12-hour time is handled in a novel way, so that the user enters >>>> a 12- >>>> hour time (e.g. 3 PM) and Rails can read it as if it''s a 24-hour >>>> time. >>>> Better documentation. >>>> Version 0.9 of bundled_resource now also includes a "stateful_form" >>>> bundle that makes it easier to store the open/closed states of form >>>> sections. This is particularly useful for AJAX forms that have >>>> hidden >>>> sections that the user can open up. When the form is submitted >>>> to the >>>> server and returned with an error, the form will retain its open/ >>>> closed states so that it''s just as the user expects it. >>>> >>>> == Download and Subversion =>>>> >>>> TAR / GZIP: http://inquirylabs.com/downloads/ >>>> bundled_resource-0.9.tgz >>>> Subversion: svn://syncid.textdriven.com/svn/opensource/ >>>> bundled_resource/trunk >>>> >>>> >>>> [1] The permalink is http://blog.inquirylabs.com/2006/01/26/ >>>> bundled- >>>> resource-v-09-full-dynarch-calendar-support/ >>> >>> >>> -- >>> Posted via http://www.ruby-forum.com/. >>> _______________________________________________ >>> Rails mailing list >>> Rails@lists.rubyonrails.org >>> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> _______________________________________________ >> Rails mailing list >> Rails@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Hmm, Javascript Console - haven''t thought to check that before. I''m in that transitional phase where Javascript/DOM stuff in general is becoming less magical and more something I can control and use, but I''m not quite there yet! I''ve got a "$ is not defined" error in dynarch_calendar/javascripts/convert_calendar_field.js at line 33. That''s the only error - no other warnings or messages of any sort. Context of line 33 is: // Replace the default Rails select boxes with our dynarch contents // alert(dynarch_contents); container = $(tag_id + ''_container''); <-------- Line 33 container.innerHTML = dynarch_contents; so it looks like that error''s quite possibly tied to what I''m (not) seeing. Regards Dave M. On 28/02/06, Duane Johnson <duane.johnson@gmail.com> wrote:> Hi David, > > The dynarch_date_select renders the normal rails date_select at > first, and then adds a little javascript right after it to convert it > to a dynarch calendar. This is mostly for backwards compatibility so > that browsers without JS enabled can still select a date. So that > would (hopefully) explain the origin of your situation... however, > why it''s not converting to a dynarch calendar as it should, I''m not > sure... have you checked the Javascript Console to see if you''re > getting any errors? > > Duane Johnson > (canadaduane) > http://blog.inquirylabs.com/ > > On Feb 27, 2006, at 8:26 PM, David Mitchell wrote: > > > Hello guys, > > > > I''m having trouble with bundled_resource plugin, trying to get a > > dynarch_date_select going... > > > > I''ve got the following in my layout file: > > <head> > > <title>ABC123</title> > > <%= stylesheet_auto_link_tags %> > > <%= stylesheet_auto_include_tags %> > > ... > > </head> > > ... > > > > In my view (actually it''s a _form.rhtml), > > <%= error_messages_for ''...'' %> > > <% require_bundle :dynarch_calendar %> > > ... > > <%= dynarch_date_select "tablename", "fieldname" %> > > > > When I render this in Firefox, I see something identical to what I > > would see if I was using good old date_select. ''View source'' shows me > > a bunch of drop down boxes, identical to what I''d see from > > date_select. > > > > In the log file, I can see a bunch of dynarch_calendar .jss files all > > being loaded successfully (i.e. they''re returning 200s). > > > > I''m fairly sure I must''ve missed out a step, but I can''t find it in > > the documentation anywhere. > > > > Can anybody help? > > > > Thanks in advance > > > > Dave M. > > > > > > > > > > > > On 02/02/06, Duane Johnson <duane.johnson@gmail.com> wrote: > >> I''ve improved the technique a bit so that this conflict no longer > >> occurs. The changes are in subversion: > >> > >> svn://syncid.textdriven.com/svn/opensource/bundled_resource/trunk > >> > >> Hopefully this will make life easier! > >> Duane > >> > >> On Jan 30, 2006, at 4:00 PM, Steve Ross wrote: > >> > >>> Duane-- > >>> > >>> I''m using the login_engine and it works just fine until I install > >>> the > >>> bundled resource plugin. Evidently, Rails loads bundled resource > >>> first > >>> (alphabetical order?), which does a require on ''application_helper''. > >>> > >>> My application_helper, of course, includes login_engine which has > >>> not > >>> yet been loaded. So, the whole thing spits up. > >>> > >>> Is there a known way to affect the load order to work around this? > >>> > >>> Thanks, > >>> > >>> Steve Ross > >>> > >>> > >>> Duane Johnson wrote: > >>>> Original announcement at http://blog.inquirylabs.com/ [1] > >>>> > >>>> == What is bundled_resource? => >>>> > >>>> If your development is in any way similar to mine, there are a > >>>> number > >>>> of useful resources out there that make web applications shine > >>>> beautifully. For example, there''s the Dynarch calendar and the > >>>> textarea tools. There are a number of others?too many, in fact. The > >>>> problem is that as a web developer, it sometimes takes some real > >>>> surgery to put each one of these in to an application. And then > >>>> when > >>>> you create a new page that uses these resources (even within the > >>>> same > >>>> app), you have to figure out which pieces to cut and paste to > >>>> get it > >>>> functional. Take the Dynarch calendar, for instance. There are 4 > >>>> javascript files, 1 CSS file (among several to choose from), 2 > >>>> images, several helper methods, and a controller method that you''ll > >>>> need in order to get it to work with Rails. Sometimes it''s easier > >>>> just to ignore the calendar bit because it''s such a pain to set up. > >>>> > >>>> The bundled_resource plugin makes it trivially easy to keep all of > >>>> these pieces together, and to include each "bundle" with a single > >>>> method, require_bundle, wherever the bundle is needed. > >>>> > >>>> == Examples => >>>> > >>>> <%= require_bundle :dynarch_calendar, > >>>> :color => ''green'', > >>>> :language => ''en'', > >>>> :icon => ''/images/my_calendar.gif'' %> > >>>> > >>>> <%= dynarch_date_select ''user'', ''birthday'' %> > >>>> > >>>> <%= dynarch_datetime_select ''user'', ''lunch_meeting'' %> > >>>> > >>>> == What''s new in v. 0.9? => >>>> > >>>> This release marks a much improved and nearly completely rewritten > >>>> dynarch calendar bundle. > >>>> > >>>> Here''s what''s new: > >>>> > >>>> It is no longer necessary to call convert_date_to_multi_params! in > >>>> your controller > >>>> Backwards compatibility for non-javascript browsers is now > >>>> improved. > >>>> Calling dynarch_date_select will call the built-in rails > >>>> date_select > >>>> method so that users whose browsers have no javascript can still > >>>> select a date in a reasonable way. > >>>> There is no longer an obnoxious ":date" field in the returned > >>>> multiparameter values. > >>>> Bundles now accept optional parameters. For the dynarch_calendar > >>>> bundle, you can specify the color stylesheet, language and icon for > >>>> your dynarch calendar. > >>>> 12-hour time is handled in a novel way, so that the user enters > >>>> a 12- > >>>> hour time (e.g. 3 PM) and Rails can read it as if it''s a 24-hour > >>>> time. > >>>> Better documentation. > >>>> Version 0.9 of bundled_resource now also includes a "stateful_form" > >>>> bundle that makes it easier to store the open/closed states of form > >>>> sections. This is particularly useful for AJAX forms that have > >>>> hidden > >>>> sections that the user can open up. When the form is submitted > >>>> to the > >>>> server and returned with an error, the form will retain its open/ > >>>> closed states so that it''s just as the user expects it. > >>>> > >>>> == Download and Subversion => >>>> > >>>> TAR / GZIP: http://inquirylabs.com/downloads/ > >>>> bundled_resource-0.9.tgz > >>>> Subversion: svn://syncid.textdriven.com/svn/opensource/ > >>>> bundled_resource/trunk > >>>> > >>>> > >>>> [1] The permalink is http://blog.inquirylabs.com/2006/01/26/ > >>>> bundled- > >>>> resource-v-09-full-dynarch-calendar-support/ > >>> > >>> > >>> -- > >>> Posted via http://www.ruby-forum.com/. > >>> _______________________________________________ > >>> Rails mailing list > >>> Rails@lists.rubyonrails.org > >>> http://lists.rubyonrails.org/mailman/listinfo/rails > >> > >> _______________________________________________ > >> Rails mailing list > >> Rails@lists.rubyonrails.org > >> http://lists.rubyonrails.org/mailman/listinfo/rails > >> > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Lots of this ''newfangled'' stuff requires XHTML that validates or the browser will fall back from "standards" mode into "compatible" mode, occasionally breaking things that are otherwise OK. I don''t know that if that''s what''s happening here, but it may be worth checking into. -- -- Tom Mornini On Feb 27, 2006, at 8:26 PM, Duane Johnson wrote:> The dynarch_date_select renders the normal rails date_select at > first, and then adds a little javascript right after it to convert > it to a dynarch calendar. This is mostly for backwards > compatibility so that browsers without JS enabled can still select > a date. So that would (hopefully) explain the origin of your > situation... however, why it''s not converting to a dynarch calendar > as it should, I''m not sure... have you checked the Javascript > Console to see if you''re getting any errors? > > Duane Johnson > (canadaduane) > http://blog.inquirylabs.com/ > > On Feb 27, 2006, at 8:26 PM, David Mitchell wrote: > >> Hello guys, >> >> I''m having trouble with bundled_resource plugin, trying to get a >> dynarch_date_select going... >> >> I''ve got the following in my layout file: >> <head> >> <title>ABC123</title> >> <%= stylesheet_auto_link_tags %> >> <%= stylesheet_auto_include_tags %> >> ... >> </head> >> ... >> >> In my view (actually it''s a _form.rhtml), >> <%= error_messages_for ''...'' %> >> <% require_bundle :dynarch_calendar %> >> ... >> <%= dynarch_date_select "tablename", "fieldname" %> >> >> When I render this in Firefox, I see something identical to what I >> would see if I was using good old date_select. ''View source'' >> shows me >> a bunch of drop down boxes, identical to what I''d see from >> date_select. >> >> In the log file, I can see a bunch of dynarch_calendar .jss files all >> being loaded successfully (i.e. they''re returning 200s). >> >> I''m fairly sure I must''ve missed out a step, but I can''t find it in >> the documentation anywhere. >> >> Can anybody help? >> >> Thanks in advance >> >> Dave M. >> >> >> >> >> >> On 02/02/06, Duane Johnson <duane.johnson@gmail.com> wrote: >>> I''ve improved the technique a bit so that this conflict no longer >>> occurs. The changes are in subversion: >>> >>> svn://syncid.textdriven.com/svn/opensource/bundled_resource/trunk >>> >>> Hopefully this will make life easier! >>> Duane >>> >>> On Jan 30, 2006, at 4:00 PM, Steve Ross wrote: >>> >>>> Duane-- >>>> >>>> I''m using the login_engine and it works just fine until I >>>> install the >>>> bundled resource plugin. Evidently, Rails loads bundled resource >>>> first >>>> (alphabetical order?), which does a require on >>>> ''application_helper''. >>>> >>>> My application_helper, of course, includes login_engine which >>>> has not >>>> yet been loaded. So, the whole thing spits up. >>>> >>>> Is there a known way to affect the load order to work around this? >>>> >>>> Thanks, >>>> >>>> Steve Ross >>>> >>>> >>>> Duane Johnson wrote: >>>>> Original announcement at http://blog.inquirylabs.com/ [1] >>>>> >>>>> == What is bundled_resource? =>>>>> >>>>> If your development is in any way similar to mine, there are a >>>>> number >>>>> of useful resources out there that make web applications shine >>>>> beautifully. For example, there''s the Dynarch calendar and the >>>>> textarea tools. There are a number of others?too many, in fact. >>>>> The >>>>> problem is that as a web developer, it sometimes takes some real >>>>> surgery to put each one of these in to an application. And then >>>>> when >>>>> you create a new page that uses these resources (even within >>>>> the same >>>>> app), you have to figure out which pieces to cut and paste to >>>>> get it >>>>> functional. Take the Dynarch calendar, for instance. There are 4 >>>>> javascript files, 1 CSS file (among several to choose from), 2 >>>>> images, several helper methods, and a controller method that >>>>> you''ll >>>>> need in order to get it to work with Rails. Sometimes it''s easier >>>>> just to ignore the calendar bit because it''s such a pain to set >>>>> up. >>>>> >>>>> The bundled_resource plugin makes it trivially easy to keep all of >>>>> these pieces together, and to include each "bundle" with a single >>>>> method, require_bundle, wherever the bundle is needed. >>>>> >>>>> == Examples =>>>>> >>>>> <%= require_bundle :dynarch_calendar, >>>>> :color => ''green'', >>>>> :language => ''en'', >>>>> :icon => ''/images/my_calendar.gif'' %> >>>>> >>>>> <%= dynarch_date_select ''user'', ''birthday'' %> >>>>> >>>>> <%= dynarch_datetime_select ''user'', ''lunch_meeting'' %> >>>>> >>>>> == What''s new in v. 0.9? =>>>>> >>>>> This release marks a much improved and nearly completely rewritten >>>>> dynarch calendar bundle. >>>>> >>>>> Here''s what''s new: >>>>> >>>>> It is no longer necessary to call convert_date_to_multi_params! in >>>>> your controller >>>>> Backwards compatibility for non-javascript browsers is now >>>>> improved. >>>>> Calling dynarch_date_select will call the built-in rails >>>>> date_select >>>>> method so that users whose browsers have no javascript can still >>>>> select a date in a reasonable way. >>>>> There is no longer an obnoxious ":date" field in the returned >>>>> multiparameter values. >>>>> Bundles now accept optional parameters. For the dynarch_calendar >>>>> bundle, you can specify the color stylesheet, language and icon >>>>> for >>>>> your dynarch calendar. >>>>> 12-hour time is handled in a novel way, so that the user enters >>>>> a 12- >>>>> hour time (e.g. 3 PM) and Rails can read it as if it''s a 24-hour >>>>> time. >>>>> Better documentation. >>>>> Version 0.9 of bundled_resource now also includes a >>>>> "stateful_form" >>>>> bundle that makes it easier to store the open/closed states of >>>>> form >>>>> sections. This is particularly useful for AJAX forms that have >>>>> hidden >>>>> sections that the user can open up. When the form is submitted >>>>> to the >>>>> server and returned with an error, the form will retain its open/ >>>>> closed states so that it''s just as the user expects it. >>>>> >>>>> == Download and Subversion =>>>>> >>>>> TAR / GZIP: http://inquirylabs.com/downloads/ >>>>> bundled_resource-0.9.tgz >>>>> Subversion: svn://syncid.textdriven.com/svn/opensource/ >>>>> bundled_resource/trunk >>>>> >>>>> >>>>> [1] The permalink is http://blog.inquirylabs.com/2006/01/26/ >>>>> bundled- >>>>> resource-v-09-full-dynarch-calendar-support/ >>>> >>>> >>>> -- >>>> Posted via http://www.ruby-forum.com/. >>>> _______________________________________________ >>>> Rails mailing list >>>> Rails@lists.rubyonrails.org >>>> http://lists.rubyonrails.org/mailman/listinfo/rails >>> >>> _______________________________________________ >>> Rails mailing list >>> Rails@lists.rubyonrails.org >>> http://lists.rubyonrails.org/mailman/listinfo/rails >>> >> _______________________________________________ >> Rails mailing list >> Rails@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Done a bit more research, and the problem is happening on IE6 on XP, Firefox 1.07 on Ubuntu Linux, and Firefox 1.5 on XP. That''s the only full-strength browsers I''ve got... I also re-downloaded bundled_resource and confirmed the problem exists on both the latest (0.9) release as well as the trunk svn code. Uncommenting the "alert" line immediately prior to the line giving the error pops up a block of HTML that looks "reasonable", for want of another term. This HTML is what''s being referenced by the line giving me the error; with my limited understanding of Javascript, it almost looks like a syntax error in convert_calendar_field.js, but that couldn''t be the case because others are using this library without problems. The relevant lines of code (lines 32-34 of convert_calendar_field.js are shown below: // Replace the default Rails select boxes with our dynarch contents alert("Contents for " + tag_id + ''_container'' + ": \n" + dynarch_contents); container = $(tag_id + ''_container''); The alert line is normally commented out, but uncommenting it causes the "dynarch_contents" to be displayed. Simple question: is the last of these 3 lines actually valid Javascript? What should it be doing? Regards Dave M. On 28/02/06, Tom Mornini <tmornini@infomania.com> wrote:> Lots of this ''newfangled'' stuff requires XHTML that validates or > the browser will fall back from "standards" mode into "compatible" > mode, occasionally breaking things that are otherwise OK. > > I don''t know that if that''s what''s happening here, but it may be > worth checking into. > > -- > -- Tom Mornini > > On Feb 27, 2006, at 8:26 PM, Duane Johnson wrote: > > > The dynarch_date_select renders the normal rails date_select at > > first, and then adds a little javascript right after it to convert > > it to a dynarch calendar. This is mostly for backwards > > compatibility so that browsers without JS enabled can still select > > a date. So that would (hopefully) explain the origin of your > > situation... however, why it''s not converting to a dynarch calendar > > as it should, I''m not sure... have you checked the Javascript > > Console to see if you''re getting any errors? > > > > Duane Johnson > > (canadaduane) > > http://blog.inquirylabs.com/ > > > > On Feb 27, 2006, at 8:26 PM, David Mitchell wrote: > > > >> Hello guys, > >> > >> I''m having trouble with bundled_resource plugin, trying to get a > >> dynarch_date_select going... > >> > >> I''ve got the following in my layout file: > >> <head> > >> <title>ABC123</title> > >> <%= stylesheet_auto_link_tags %> > >> <%= stylesheet_auto_include_tags %> > >> ... > >> </head> > >> ... > >> > >> In my view (actually it''s a _form.rhtml), > >> <%= error_messages_for ''...'' %> > >> <% require_bundle :dynarch_calendar %> > >> ... > >> <%= dynarch_date_select "tablename", "fieldname" %> > >> > >> When I render this in Firefox, I see something identical to what I > >> would see if I was using good old date_select. ''View source'' > >> shows me > >> a bunch of drop down boxes, identical to what I''d see from > >> date_select. > >> > >> In the log file, I can see a bunch of dynarch_calendar .jss files all > >> being loaded successfully (i.e. they''re returning 200s). > >> > >> I''m fairly sure I must''ve missed out a step, but I can''t find it in > >> the documentation anywhere. > >> > >> Can anybody help? > >> > >> Thanks in advance > >> > >> Dave M. > >> > >> > >> > >> > >> > >> On 02/02/06, Duane Johnson <duane.johnson@gmail.com> wrote: > >>> I''ve improved the technique a bit so that this conflict no longer > >>> occurs. The changes are in subversion: > >>> > >>> svn://syncid.textdriven.com/svn/opensource/bundled_resource/trunk > >>> > >>> Hopefully this will make life easier! > >>> Duane > >>> > >>> On Jan 30, 2006, at 4:00 PM, Steve Ross wrote: > >>> > >>>> Duane-- > >>>> > >>>> I''m using the login_engine and it works just fine until I > >>>> install the > >>>> bundled resource plugin. Evidently, Rails loads bundled resource > >>>> first > >>>> (alphabetical order?), which does a require on > >>>> ''application_helper''. > >>>> > >>>> My application_helper, of course, includes login_engine which > >>>> has not > >>>> yet been loaded. So, the whole thing spits up. > >>>> > >>>> Is there a known way to affect the load order to work around this? > >>>> > >>>> Thanks, > >>>> > >>>> Steve Ross > >>>> > >>>> > >>>> Duane Johnson wrote: > >>>>> Original announcement at http://blog.inquirylabs.com/ [1] > >>>>> > >>>>> == What is bundled_resource? => >>>>> > >>>>> If your development is in any way similar to mine, there are a > >>>>> number > >>>>> of useful resources out there that make web applications shine > >>>>> beautifully. For example, there''s the Dynarch calendar and the > >>>>> textarea tools. There are a number of others?too many, in fact. > >>>>> The > >>>>> problem is that as a web developer, it sometimes takes some real > >>>>> surgery to put each one of these in to an application. And then > >>>>> when > >>>>> you create a new page that uses these resources (even within > >>>>> the same > >>>>> app), you have to figure out which pieces to cut and paste to > >>>>> get it > >>>>> functional. Take the Dynarch calendar, for instance. There are 4 > >>>>> javascript files, 1 CSS file (among several to choose from), 2 > >>>>> images, several helper methods, and a controller method that > >>>>> you''ll > >>>>> need in order to get it to work with Rails. Sometimes it''s easier > >>>>> just to ignore the calendar bit because it''s such a pain to set > >>>>> up. > >>>>> > >>>>> The bundled_resource plugin makes it trivially easy to keep all of > >>>>> these pieces together, and to include each "bundle" with a single > >>>>> method, require_bundle, wherever the bundle is needed. > >>>>> > >>>>> == Examples => >>>>> > >>>>> <%= require_bundle :dynarch_calendar, > >>>>> :color => ''green'', > >>>>> :language => ''en'', > >>>>> :icon => ''/images/my_calendar.gif'' %> > >>>>> > >>>>> <%= dynarch_date_select ''user'', ''birthday'' %> > >>>>> > >>>>> <%= dynarch_datetime_select ''user'', ''lunch_meeting'' %> > >>>>> > >>>>> == What''s new in v. 0.9? => >>>>> > >>>>> This release marks a much improved and nearly completely rewritten > >>>>> dynarch calendar bundle. > >>>>> > >>>>> Here''s what''s new: > >>>>> > >>>>> It is no longer necessary to call convert_date_to_multi_params! in > >>>>> your controller > >>>>> Backwards compatibility for non-javascript browsers is now > >>>>> improved. > >>>>> Calling dynarch_date_select will call the built-in rails > >>>>> date_select > >>>>> method so that users whose browsers have no javascript can still > >>>>> select a date in a reasonable way. > >>>>> There is no longer an obnoxious ":date" field in the returned > >>>>> multiparameter values. > >>>>> Bundles now accept optional parameters. For the dynarch_calendar > >>>>> bundle, you can specify the color stylesheet, language and icon > >>>>> for > >>>>> your dynarch calendar. > >>>>> 12-hour time is handled in a novel way, so that the user enters > >>>>> a 12- > >>>>> hour time (e.g. 3 PM) and Rails can read it as if it''s a 24-hour > >>>>> time. > >>>>> Better documentation. > >>>>> Version 0.9 of bundled_resource now also includes a > >>>>> "stateful_form" > >>>>> bundle that makes it easier to store the open/closed states of > >>>>> form > >>>>> sections. This is particularly useful for AJAX forms that have > >>>>> hidden > >>>>> sections that the user can open up. When the form is submitted > >>>>> to the > >>>>> server and returned with an error, the form will retain its open/ > >>>>> closed states so that it''s just as the user expects it. > >>>>> > >>>>> == Download and Subversion => >>>>> > >>>>> TAR / GZIP: http://inquirylabs.com/downloads/ > >>>>> bundled_resource-0.9.tgz > >>>>> Subversion: svn://syncid.textdriven.com/svn/opensource/ > >>>>> bundled_resource/trunk > >>>>> > >>>>> > >>>>> [1] The permalink is http://blog.inquirylabs.com/2006/01/26/ > >>>>> bundled- > >>>>> resource-v-09-full-dynarch-calendar-support/ > >>>> > >>>> > >>>> -- > >>>> Posted via http://www.ruby-forum.com/. > >>>> _______________________________________________ > >>>> Rails mailing list > >>>> Rails@lists.rubyonrails.org > >>>> http://lists.rubyonrails.org/mailman/listinfo/rails > >>> > >>> _______________________________________________ > >>> Rails mailing list > >>> Rails@lists.rubyonrails.org > >>> http://lists.rubyonrails.org/mailman/listinfo/rails > >>> > >> _______________________________________________ > >> Rails mailing list > >> Rails@lists.rubyonrails.org > >> http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Does your markup validate? -- -- Tom Mornini On Feb 27, 2006, at 11:50 PM, David Mitchell wrote:> Done a bit more research, and the problem is happening on IE6 on XP, > Firefox 1.07 on Ubuntu Linux, and Firefox 1.5 on XP. That''s the only > full-strength browsers I''ve got... > > I also re-downloaded bundled_resource and confirmed the problem exists > on both the latest (0.9) release as well as the trunk svn code. > > Uncommenting the "alert" line immediately prior to the line giving the > error pops up a block of HTML that looks "reasonable", for want of > another term. This HTML is what''s being referenced by the line giving > me the error; with my limited understanding of Javascript, it almost > looks like a syntax error in convert_calendar_field.js, but that > couldn''t be the case because others are using this library without > problems. > > The relevant lines of code (lines 32-34 of convert_calendar_field.js > are shown below: > // Replace the default Rails select boxes with our dynarch contents > alert("Contents for " + tag_id + ''_container'' + ": \n" + > dynarch_contents); > container = $(tag_id + ''_container''); > > The alert line is normally commented out, but uncommenting it causes > the "dynarch_contents" to be displayed. > > Simple question: is the last of these 3 lines actually valid > Javascript? What should it be doing? > > Regards > > Dave M. > > On 28/02/06, Tom Mornini <tmornini@infomania.com> wrote: >> Lots of this ''newfangled'' stuff requires XHTML that validates or >> the browser will fall back from "standards" mode into "compatible" >> mode, occasionally breaking things that are otherwise OK. >> >> I don''t know that if that''s what''s happening here, but it may be >> worth checking into.
Hmm, that''s strange. I''m getting validation errors all over the place, but I don''t think they''re cause for concern... This is the start of the page: 1 <html> 2 <head> 3 <title>ABC123</title> 4 <link href="/bundles/dynarch_calendar/stylesheets/calendar-blue.css" media="screen" rel="Stylesheet" type="text/css" /> 5 6 <script src="/bundles/dynarch_calendar/javascripts/calendar_stripped.js" type="text/javascript"></script> 7 <script src="/bundles/dynarch_calendar/lang/calendar-en.js" type="text/javascript"></script> 8 <script src="/bundles/dynarch_calendar/javascripts/calendar-setup_stripped.js" type="text/javascript"></script> 9 <script src="/bundles/dynarch_calendar/javascripts/convert_calendar_field.js" type="text/javascript"></script> 10 11 <link href="/stylesheets/abc.css" media="all" rel="Stylesheet" type="text/css" /> 12 </head> And the errors for this section... # Line 1, character 1: <html> ^ Error: missing document type declaration; assuming HTML 4.01 Transitional # Line 4, character 122: ... "Stylesheet" type="text/css" /> ^ Warning: net-enabling start-tag; possibly missing required quotes around an attribute value # Line 11, character 88: ... "Stylesheet" type="text/css" /> ^ Warning: net-enabling start-tag; possibly missing required quotes around an attribute value # Line 11, character 88: ... "Stylesheet" type="text/css" /> ^ Error: element LINK not allowed here; check which elements this element may be contained within # Line 12, character 9: </head> ^ Error: end tag for element HEAD which is not open; try removing the end tag or check for improper nesting of elements Here''s the code that corresponds to this section: <html> <head> <title>ABC123</title> <%= stylesheet_auto_link_tags %> <%= javascript_auto_include_tags %> <%= stylesheet_link_tag "abc", :media => "all" %> </head> Other than these (and several similar errors, all of which are from Rails API-generated code), it validates cleanly. Not sure if that''s a good or bad thing, but I''m assuming other peoples'' pages would give similar errors yet they''re still able to render dynarch fields correctly. This has really got me stumped. Regards Dave M. On 28/02/06, Tom Mornini <tmornini@infomania.com> wrote:> Does your markup validate? > > -- > -- Tom Mornini >
On Feb 28, 2006, at 1:55 AM, David Mitchell wrote:> Hmm, that''s strange. > > I''m getting validation errors all over the place, but I don''t think > they''re cause for concern...snip...> Other than these (and several similar errors, all of which are from > Rails API-generated code), it validates cleanly. > > Not sure if that''s a good or bad thing, but I''m assuming other > peoples'' pages would give similar errors yet they''re still able to > render dynarch fields correctly.Oh, yeah, if you''re not declaring XHTML, advanced CSS and JavaScript stuff simply won''t work, as I understand it. As for other people''s markup not validating, you may be right, but I think you may be wrong. I''ve heard it again and again that lots of AJAX and JS errors and difficulties are related to non-validating markup. You may want to look at: http://www.cosinux.org/blogs/dam/pages/rails-tidy http://wiki.rubyonrails.org/rails/pages/Assert+Valid+Markup+Plugin And, I''m referencng my own test_helper.rb based routines, which are in a large part developed by "Scott Raymond" <sco@scottraymond.net> This requires two lines in your environment.rb file: VALIDATE_W3C = true VALIDATE_TIDY = true I use the Tidy validator when I''m offline, and both when I''m online. http://homepage.mac.com/tmornini/test_helper.rb -- -- Tom Mornini
All right, thanks Tom, I''ll get stuck into creating valid XHTML tomorrow (somewhere off in the distance, I hear a voice asking "When are you coming to bed?"). I''m still concerned that a lot of the invalid stuff is being generated by e.g. <% require_bundle :dynarch_calendar %>, but maybe it''ll be clearer after a night''s sleep. If anyone can post a (trivial) sample RHTML file that displays the dynarch_calendar, I''d greatly appreciate it. There''s still something I''m not comprehending here, and maybe seeing a working RHTML example would help knock it into my thick skull. Thanks again Dave M. On 28/02/06, Tom Mornini <tmornini@infomania.com> wrote:> On Feb 28, 2006, at 1:55 AM, David Mitchell wrote: > > Hmm, that''s strange. > > > > I''m getting validation errors all over the place, but I don''t think > > they''re cause for concern... > > snip... > > > Other than these (and several similar errors, all of which are from > > Rails API-generated code), it validates cleanly. > > > > Not sure if that''s a good or bad thing, but I''m assuming other > > peoples'' pages would give similar errors yet they''re still able to > > render dynarch fields correctly. > > Oh, yeah, if you''re not declaring XHTML, advanced CSS > and JavaScript stuff simply won''t work, as I understand > it. > > As for other people''s markup not validating, you may be > right, but I think you may be wrong. > > I''ve heard it again and again that lots of AJAX and JS > errors and difficulties are related to non-validating > markup. > > You may want to look at: > > http://www.cosinux.org/blogs/dam/pages/rails-tidy > > http://wiki.rubyonrails.org/rails/pages/Assert+Valid+Markup+Plugin > > And, I''m referencng my own test_helper.rb based routines, which are > in a large part developed by "Scott Raymond" <sco@scottraymond.net> > > This requires two lines in your environment.rb file: > > VALIDATE_W3C = true > VALIDATE_TIDY = true > > I use the Tidy validator when I''m offline, and both when I''m online. > > http://homepage.mac.com/tmornini/test_helper.rb > > -- > -- Tom Mornini > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Tue, 2006-02-28 at 22:15 +1100, David Mitchell wrote:> All right, thanks Tom, > > I''ll get stuck into creating valid XHTML tomorrow (somewhere off in > the distance, I hear a voice asking "When are you coming to bed?"). > I''m still concerned that a lot of the invalid stuff is being generated > by e.g. <% require_bundle :dynarch_calendar %>, but maybe it''ll be > clearer after a night''s sleep. > > If anyone can post a (trivial) sample RHTML file that displays the > dynarch_calendar, I''d greatly appreciate it. There''s still something > I''m not comprehending here, and maybe seeing a working RHTML example > would help knock it into my thick skull.---- for a number of reasons, I gave up on dynarch calendar and used the ''DatePicker'' calendar. It looks similar, is much simpler to install and make functional and doesn''t require anything other than it''s js, css & helper file. Craig
As a side not to this whole discussion, I found the same results at the originating post until I embedded the setup call for the dynarch calendar in-line with the view that the calendar was to appear in, as opposed to just sticking it at the top of a template. In my case I put: <% require_bundle :dynarch_calendar, :color => ''brown'', :language => ''en'', :icon => ''/images/MISC_calendar.gif'' %> Right before my first call to the calendar on a view. You''re requirements are of course different. But it''s at least one more thing to try before you give up the ghost. D. Taylor Singletary, Reality Technician On 2/28/06, Craig White <craigwhite@azapple.com> wrote:> > On Tue, 2006-02-28 at 22:15 +1100, David Mitchell wrote: > > All right, thanks Tom, > > > > I''ll get stuck into creating valid XHTML tomorrow (somewhere off in > > the distance, I hear a voice asking "When are you coming to bed?"). > > I''m still concerned that a lot of the invalid stuff is being generated > > by e.g. <% require_bundle :dynarch_calendar %>, but maybe it''ll be > > clearer after a night''s sleep. > > > > If anyone can post a (trivial) sample RHTML file that displays the > > dynarch_calendar, I''d greatly appreciate it. There''s still something > > I''m not comprehending here, and maybe seeing a working RHTML example > > would help knock it into my thick skull. > ---- > for a number of reasons, I gave up on dynarch calendar and used the > ''DatePicker'' calendar. > > It looks similar, is much simpler to install and make functional and > doesn''t require anything other than it''s js, css & helper file. > > Craig > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060228/f4bacdbe/attachment.html
Ha! I can''t believe I didn''t mention the dependency in the docs. The dynarch_calendar (at this point) depends on prototype.js, so be sure to include that in your headers. If you''re using the latest bundled_resource from subversion, you can use "resource_tags" and it will automatically include that for you. Duane On Feb 28, 2006, at 12:50 AM, David Mitchell wrote:> Done a bit more research, and the problem is happening on IE6 on XP, > Firefox 1.07 on Ubuntu Linux, and Firefox 1.5 on XP. That''s the only > full-strength browsers I''ve got... > > I also re-downloaded bundled_resource and confirmed the problem exists > on both the latest (0.9) release as well as the trunk svn code. > > Uncommenting the "alert" line immediately prior to the line giving the > error pops up a block of HTML that looks "reasonable", for want of > another term. This HTML is what''s being referenced by the line giving > me the error; with my limited understanding of Javascript, it almost > looks like a syntax error in convert_calendar_field.js, but that > couldn''t be the case because others are using this library without > problems. > > The relevant lines of code (lines 32-34 of convert_calendar_field.js > are shown below: > // Replace the default Rails select boxes with our dynarch contents > alert("Contents for " + tag_id + ''_container'' + ": \n" + > dynarch_contents); > container = $(tag_id + ''_container''); > > The alert line is normally commented out, but uncommenting it causes > the "dynarch_contents" to be displayed. > > Simple question: is the last of these 3 lines actually valid > Javascript? What should it be doing? > > Regards > > Dave M. > > > On 28/02/06, Tom Mornini <tmornini@infomania.com> wrote: >> Lots of this ''newfangled'' stuff requires XHTML that validates or >> the browser will fall back from "standards" mode into "compatible" >> mode, occasionally breaking things that are otherwise OK. >> >> I don''t know that if that''s what''s happening here, but it may be >> worth checking into. >> >> -- >> -- Tom Mornini >> >> On Feb 27, 2006, at 8:26 PM, Duane Johnson wrote: >> >>> The dynarch_date_select renders the normal rails date_select at >>> first, and then adds a little javascript right after it to convert >>> it to a dynarch calendar. This is mostly for backwards >>> compatibility so that browsers without JS enabled can still select >>> a date. So that would (hopefully) explain the origin of your >>> situation... however, why it''s not converting to a dynarch calendar >>> as it should, I''m not sure... have you checked the Javascript >>> Console to see if you''re getting any errors? >>> >>> Duane Johnson >>> (canadaduane) >>> http://blog.inquirylabs.com/ >>> >>> On Feb 27, 2006, at 8:26 PM, David Mitchell wrote: >>> >>>> Hello guys, >>>> >>>> I''m having trouble with bundled_resource plugin, trying to get a >>>> dynarch_date_select going... >>>> >>>> I''ve got the following in my layout file: >>>> <head> >>>> <title>ABC123</title> >>>> <%= stylesheet_auto_link_tags %> >>>> <%= stylesheet_auto_include_tags %> >>>> ... >>>> </head> >>>> ... >>>> >>>> In my view (actually it''s a _form.rhtml), >>>> <%= error_messages_for ''...'' %> >>>> <% require_bundle :dynarch_calendar %> >>>> ... >>>> <%= dynarch_date_select "tablename", "fieldname" %> >>>> >>>> When I render this in Firefox, I see something identical to what I >>>> would see if I was using good old date_select. ''View source'' >>>> shows me >>>> a bunch of drop down boxes, identical to what I''d see from >>>> date_select. >>>> >>>> In the log file, I can see a bunch of dynarch_calendar .jss >>>> files all >>>> being loaded successfully (i.e. they''re returning 200s). >>>> >>>> I''m fairly sure I must''ve missed out a step, but I can''t find it in >>>> the documentation anywhere. >>>> >>>> Can anybody help? >>>> >>>> Thanks in advance >>>> >>>> Dave M. >>>> >>>> >>>> >>>> >>>> >>>> On 02/02/06, Duane Johnson <duane.johnson@gmail.com> wrote: >>>>> I''ve improved the technique a bit so that this conflict no longer >>>>> occurs. The changes are in subversion: >>>>> >>>>> svn://syncid.textdriven.com/svn/opensource/bundled_resource/trunk >>>>> >>>>> Hopefully this will make life easier! >>>>> Duane >>>>> >>>>> On Jan 30, 2006, at 4:00 PM, Steve Ross wrote: >>>>> >>>>>> Duane-- >>>>>> >>>>>> I''m using the login_engine and it works just fine until I >>>>>> install the >>>>>> bundled resource plugin. Evidently, Rails loads bundled resource >>>>>> first >>>>>> (alphabetical order?), which does a require on >>>>>> ''application_helper''. >>>>>> >>>>>> My application_helper, of course, includes login_engine which >>>>>> has not >>>>>> yet been loaded. So, the whole thing spits up. >>>>>> >>>>>> Is there a known way to affect the load order to work around >>>>>> this? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Steve Ross >>>>>> >>>>>> >>>>>> Duane Johnson wrote: >>>>>>> Original announcement at http://blog.inquirylabs.com/ [1] >>>>>>> >>>>>>> == What is bundled_resource? =>>>>>>> >>>>>>> If your development is in any way similar to mine, there are a >>>>>>> number >>>>>>> of useful resources out there that make web applications shine >>>>>>> beautifully. For example, there''s the Dynarch calendar and the >>>>>>> textarea tools. There are a number of others?too many, in fact. >>>>>>> The >>>>>>> problem is that as a web developer, it sometimes takes some real >>>>>>> surgery to put each one of these in to an application. And then >>>>>>> when >>>>>>> you create a new page that uses these resources (even within >>>>>>> the same >>>>>>> app), you have to figure out which pieces to cut and paste to >>>>>>> get it >>>>>>> functional. Take the Dynarch calendar, for instance. There are 4 >>>>>>> javascript files, 1 CSS file (among several to choose from), 2 >>>>>>> images, several helper methods, and a controller method that >>>>>>> you''ll >>>>>>> need in order to get it to work with Rails. Sometimes it''s >>>>>>> easier >>>>>>> just to ignore the calendar bit because it''s such a pain to set >>>>>>> up. >>>>>>> >>>>>>> The bundled_resource plugin makes it trivially easy to keep >>>>>>> all of >>>>>>> these pieces together, and to include each "bundle" with a >>>>>>> single >>>>>>> method, require_bundle, wherever the bundle is needed. >>>>>>> >>>>>>> == Examples =>>>>>>> >>>>>>> <%= require_bundle :dynarch_calendar, >>>>>>> :color => ''green'', >>>>>>> :language => ''en'', >>>>>>> :icon => ''/images/my_calendar.gif'' %> >>>>>>> >>>>>>> <%= dynarch_date_select ''user'', ''birthday'' %> >>>>>>> >>>>>>> <%= dynarch_datetime_select ''user'', ''lunch_meeting'' %> >>>>>>> >>>>>>> == What''s new in v. 0.9? =>>>>>>> >>>>>>> This release marks a much improved and nearly completely >>>>>>> rewritten >>>>>>> dynarch calendar bundle. >>>>>>> >>>>>>> Here''s what''s new: >>>>>>> >>>>>>> It is no longer necessary to call >>>>>>> convert_date_to_multi_params! in >>>>>>> your controller >>>>>>> Backwards compatibility for non-javascript browsers is now >>>>>>> improved. >>>>>>> Calling dynarch_date_select will call the built-in rails >>>>>>> date_select >>>>>>> method so that users whose browsers have no javascript can still >>>>>>> select a date in a reasonable way. >>>>>>> There is no longer an obnoxious ":date" field in the returned >>>>>>> multiparameter values. >>>>>>> Bundles now accept optional parameters. For the dynarch_calendar >>>>>>> bundle, you can specify the color stylesheet, language and icon >>>>>>> for >>>>>>> your dynarch calendar. >>>>>>> 12-hour time is handled in a novel way, so that the user enters >>>>>>> a 12- >>>>>>> hour time (e.g. 3 PM) and Rails can read it as if it''s a 24-hour >>>>>>> time. >>>>>>> Better documentation. >>>>>>> Version 0.9 of bundled_resource now also includes a >>>>>>> "stateful_form" >>>>>>> bundle that makes it easier to store the open/closed states of >>>>>>> form >>>>>>> sections. This is particularly useful for AJAX forms that have >>>>>>> hidden >>>>>>> sections that the user can open up. When the form is submitted >>>>>>> to the >>>>>>> server and returned with an error, the form will retain its >>>>>>> open/ >>>>>>> closed states so that it''s just as the user expects it. >>>>>>> >>>>>>> == Download and Subversion =>>>>>>> >>>>>>> TAR / GZIP: http://inquirylabs.com/downloads/ >>>>>>> bundled_resource-0.9.tgz >>>>>>> Subversion: svn://syncid.textdriven.com/svn/opensource/ >>>>>>> bundled_resource/trunk >>>>>>> >>>>>>> >>>>>>> [1] The permalink is http://blog.inquirylabs.com/2006/01/26/ >>>>>>> bundled- >>>>>>> resource-v-09-full-dynarch-calendar-support/ >>>>>> >>>>>> >>>>>> -- >>>>>> Posted via http://www.ruby-forum.com/. >>>>>> _______________________________________________ >>>>>> Rails mailing list >>>>>> Rails@lists.rubyonrails.org >>>>>> http://lists.rubyonrails.org/mailman/listinfo/rails >>>>> >>>>> _______________________________________________ >>>>> Rails mailing list >>>>> Rails@lists.rubyonrails.org >>>>> http://lists.rubyonrails.org/mailman/listinfo/rails >>>>> >>>> _______________________________________________ >>>> Rails mailing list >>>> Rails@lists.rubyonrails.org >>>> http://lists.rubyonrails.org/mailman/listinfo/rails >>> >>> _______________________________________________ >>> Rails mailing list >>> Rails@lists.rubyonrails.org >>> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> _______________________________________________ >> Rails mailing list >> Rails@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On Feb 28, 2006, at 7:36 AM, D. Taylor Singletary wrote:> As a side not to this whole discussion, I found the same results at > the originating post until I embedded the setup call for the > dynarch calendar in-line with the view that the calendar was to > appear in, as opposed to just sticking it at the top of a template. > In my case I put: > > <% require_bundle :dynarch_calendar, > :color => ''brown'', > :language => ''en'', > :icon => ''/images/MISC_calendar.gif'' %> > > Right before my first call to the calendar on a view. You''re > requirements are of course different. But it''s at least one more > thing to try before you give up the ghost. > > D. Taylor Singletary, > Reality Technician >Thanks, Taylor. That''s something else I missed in the docs. Definitely want to put the require_bundle call in the view where you are calling dynarch_date_select (and friends). I''ll be writing up some docs on this plugin soon enough. Sorry to throw anyone for a loop! Duane Johnson (canadaduane) http://blog.inquirylabs.com/
Unfortunately, the closing slash is not valid in html 4 on several elements. Someone posted a plugin a week or two ago to suppress closing slashes. However, it would seem more practical to use the xhtml 1.0 transitional doctype, which allows the closing slashes (in fact it enforces xml-valid markup) but is more forgiving about other old html elements that you may be using. Note that there is some controversey about this because the w3c recommends sending xthml with an application/xml-xhtml mime type. However, as some people have argued, all modern browsers will do the right thing with the xhtml 1.0 doc type and the text/html mime type. (And I''m taking up a collection to have the entire IE dev team killed... care to contribute?) b PS: here''s an article about doctypes: http://www.alistapart.com/articles/doctype/ and here''s an explanation of how browsers use them: http://www.quirksmode.org/css/quirksmode.html David Mitchell wrote:> Hmm, that''s strange. > > I''m getting validation errors all over the place, but I don''t think > they''re cause for concern... > > This is the start of the page: > 1 <html> > 2 <head> > 3 <title>ABC123</title> > 4 <link > href="/bundles/dynarch_calendar/stylesheets/calendar-blue.css" > media="screen" rel="Stylesheet" type="text/css" /> > 5 > 6 <script > src="/bundles/dynarch_calendar/javascripts/calendar_stripped.js" > type="text/javascript"></script> > 7 <script src="/bundles/dynarch_calendar/lang/calendar-en.js" > type="text/javascript"></script> > 8 <script > src="/bundles/dynarch_calendar/javascripts/calendar-setup_stripped.js" > type="text/javascript"></script> > 9 <script > src="/bundles/dynarch_calendar/javascripts/convert_calendar_field.js" > type="text/javascript"></script> > 10 > 11 <link href="/stylesheets/abc.css" media="all" > rel="Stylesheet" type="text/css" /> > 12 </head> > > And the errors for this section... > > # Line 1, character 1: > > <html> > ^ > > Error: missing document type declaration; assuming HTML 4.01 Transitional > # Line 4, character 122: > > ... "Stylesheet" type="text/css" /> > ^ > > Warning: net-enabling start-tag; possibly missing required quotes > around an attribute value > # Line 11, character 88: > > ... "Stylesheet" type="text/css" /> > ^ > > Warning: net-enabling start-tag; possibly missing required quotes > around an attribute value > # Line 11, character 88: > > ... "Stylesheet" type="text/css" /> > ^ > > Error: element LINK not allowed here; check which elements this > element may be contained within > # Line 12, character 9: > > </head> > ^ > > Error: end tag for element HEAD which is not open; try removing the > end tag or check for improper nesting of elements > > Here''s the code that corresponds to this section: > <html> > <head> > <title>ABC123</title> > <%= stylesheet_auto_link_tags %> > <%= javascript_auto_include_tags %> > <%= stylesheet_link_tag "abc", :media => "all" %> > </head> > > Other than these (and several similar errors, all of which are from > Rails API-generated code), it validates cleanly. > > Not sure if that''s a good or bad thing, but I''m assuming other > peoples'' pages would give similar errors yet they''re still able to > render dynarch fields correctly. > > This has really got me stumped. > > Regards > > Dave M. > > > > > On 28/02/06, Tom Mornini <tmornini@infomania.com> wrote: > >>Does your markup validate? >> >>-- >>-- Tom Mornini >> > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Thanks Duane, That was it - I had to put <%= define_javascript_functions %> in the <head> section of my page, and then everything worked fine. Thanks also to everyone else who responded; this is a great mailing list because of people like yourselves, willing to help out a guy who''s struggling. I wish more lists were like this one. Regards Dave M. On 01/03/06, Duane Johnson <duane.johnson@gmail.com> wrote:> Ha! I can''t believe I didn''t mention the dependency in the docs. > The dynarch_calendar (at this point) depends on prototype.js, so be > sure to include that in your headers. > > If you''re using the latest bundled_resource from subversion, you can > use "resource_tags" and it will automatically include that for you. > > Duane > > On Feb 28, 2006, at 12:50 AM, David Mitchell wrote: > > > Done a bit more research, and the problem is happening on IE6 on XP, > > Firefox 1.07 on Ubuntu Linux, and Firefox 1.5 on XP. That''s the only > > full-strength browsers I''ve got... > > > > I also re-downloaded bundled_resource and confirmed the problem exists > > on both the latest (0.9) release as well as the trunk svn code. > > > > Uncommenting the "alert" line immediately prior to the line giving the > > error pops up a block of HTML that looks "reasonable", for want of > > another term. This HTML is what''s being referenced by the line giving > > me the error; with my limited understanding of Javascript, it almost > > looks like a syntax error in convert_calendar_field.js, but that > > couldn''t be the case because others are using this library without > > problems. > > > > The relevant lines of code (lines 32-34 of convert_calendar_field.js > > are shown below: > > // Replace the default Rails select boxes with our dynarch contents > > alert("Contents for " + tag_id + ''_container'' + ": \n" + > > dynarch_contents); > > container = $(tag_id + ''_container''); > > > > The alert line is normally commented out, but uncommenting it causes > > the "dynarch_contents" to be displayed. > > > > Simple question: is the last of these 3 lines actually valid > > Javascript? What should it be doing? > > > > Regards > > > > Dave M. > > > > > > On 28/02/06, Tom Mornini <tmornini@infomania.com> wrote: > >> Lots of this ''newfangled'' stuff requires XHTML that validates or > >> the browser will fall back from "standards" mode into "compatible" > >> mode, occasionally breaking things that are otherwise OK. > >> > >> I don''t know that if that''s what''s happening here, but it may be > >> worth checking into. > >> > >> -- > >> -- Tom Mornini > >> > >> On Feb 27, 2006, at 8:26 PM, Duane Johnson wrote: > >> > >>> The dynarch_date_select renders the normal rails date_select at > >>> first, and then adds a little javascript right after it to convert > >>> it to a dynarch calendar. This is mostly for backwards > >>> compatibility so that browsers without JS enabled can still select > >>> a date. So that would (hopefully) explain the origin of your > >>> situation... however, why it''s not converting to a dynarch calendar > >>> as it should, I''m not sure... have you checked the Javascript > >>> Console to see if you''re getting any errors? > >>> > >>> Duane Johnson > >>> (canadaduane) > >>> http://blog.inquirylabs.com/ > >>> > >>> On Feb 27, 2006, at 8:26 PM, David Mitchell wrote: > >>> > >>>> Hello guys, > >>>> > >>>> I''m having trouble with bundled_resource plugin, trying to get a > >>>> dynarch_date_select going... > >>>> > >>>> I''ve got the following in my layout file: > >>>> <head> > >>>> <title>ABC123</title> > >>>> <%= stylesheet_auto_link_tags %> > >>>> <%= stylesheet_auto_include_tags %> > >>>> ... > >>>> </head> > >>>> ... > >>>> > >>>> In my view (actually it''s a _form.rhtml), > >>>> <%= error_messages_for ''...'' %> > >>>> <% require_bundle :dynarch_calendar %> > >>>> ... > >>>> <%= dynarch_date_select "tablename", "fieldname" %> > >>>> > >>>> When I render this in Firefox, I see something identical to what I > >>>> would see if I was using good old date_select. ''View source'' > >>>> shows me > >>>> a bunch of drop down boxes, identical to what I''d see from > >>>> date_select. > >>>> > >>>> In the log file, I can see a bunch of dynarch_calendar .jss > >>>> files all > >>>> being loaded successfully (i.e. they''re returning 200s). > >>>> > >>>> I''m fairly sure I must''ve missed out a step, but I can''t find it in > >>>> the documentation anywhere. > >>>> > >>>> Can anybody help? > >>>> > >>>> Thanks in advance > >>>> > >>>> Dave M. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On 02/02/06, Duane Johnson <duane.johnson@gmail.com> wrote: > >>>>> I''ve improved the technique a bit so that this conflict no longer > >>>>> occurs. The changes are in subversion: > >>>>> > >>>>> svn://syncid.textdriven.com/svn/opensource/bundled_resource/trunk > >>>>> > >>>>> Hopefully this will make life easier! > >>>>> Duane > >>>>> > >>>>> On Jan 30, 2006, at 4:00 PM, Steve Ross wrote: > >>>>> > >>>>>> Duane-- > >>>>>> > >>>>>> I''m using the login_engine and it works just fine until I > >>>>>> install the > >>>>>> bundled resource plugin. Evidently, Rails loads bundled resource > >>>>>> first > >>>>>> (alphabetical order?), which does a require on > >>>>>> ''application_helper''. > >>>>>> > >>>>>> My application_helper, of course, includes login_engine which > >>>>>> has not > >>>>>> yet been loaded. So, the whole thing spits up. > >>>>>> > >>>>>> Is there a known way to affect the load order to work around > >>>>>> this? > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Steve Ross > >>>>>> > >>>>>> > >>>>>> Duane Johnson wrote: > >>>>>>> Original announcement at http://blog.inquirylabs.com/ [1] > >>>>>>> > >>>>>>> == What is bundled_resource? => >>>>>>> > >>>>>>> If your development is in any way similar to mine, there are a > >>>>>>> number > >>>>>>> of useful resources out there that make web applications shine > >>>>>>> beautifully. For example, there''s the Dynarch calendar and the > >>>>>>> textarea tools. There are a number of others?too many, in fact. > >>>>>>> The > >>>>>>> problem is that as a web developer, it sometimes takes some real > >>>>>>> surgery to put each one of these in to an application. And then > >>>>>>> when > >>>>>>> you create a new page that uses these resources (even within > >>>>>>> the same > >>>>>>> app), you have to figure out which pieces to cut and paste to > >>>>>>> get it > >>>>>>> functional. Take the Dynarch calendar, for instance. There are 4 > >>>>>>> javascript files, 1 CSS file (among several to choose from), 2 > >>>>>>> images, several helper methods, and a controller method that > >>>>>>> you''ll > >>>>>>> need in order to get it to work with Rails. Sometimes it''s > >>>>>>> easier > >>>>>>> just to ignore the calendar bit because it''s such a pain to set > >>>>>>> up. > >>>>>>> > >>>>>>> The bundled_resource plugin makes it trivially easy to keep > >>>>>>> all of > >>>>>>> these pieces together, and to include each "bundle" with a > >>>>>>> single > >>>>>>> method, require_bundle, wherever the bundle is needed. > >>>>>>> > >>>>>>> == Examples => >>>>>>> > >>>>>>> <%= require_bundle :dynarch_calendar, > >>>>>>> :color => ''green'', > >>>>>>> :language => ''en'', > >>>>>>> :icon => ''/images/my_calendar.gif'' %> > >>>>>>> > >>>>>>> <%= dynarch_date_select ''user'', ''birthday'' %> > >>>>>>> > >>>>>>> <%= dynarch_datetime_select ''user'', ''lunch_meeting'' %> > >>>>>>> > >>>>>>> == What''s new in v. 0.9? => >>>>>>> > >>>>>>> This release marks a much improved and nearly completely > >>>>>>> rewritten > >>>>>>> dynarch calendar bundle. > >>>>>>> > >>>>>>> Here''s what''s new: > >>>>>>> > >>>>>>> It is no longer necessary to call > >>>>>>> convert_date_to_multi_params! in > >>>>>>> your controller > >>>>>>> Backwards compatibility for non-javascript browsers is now > >>>>>>> improved. > >>>>>>> Calling dynarch_date_select will call the built-in rails > >>>>>>> date_select > >>>>>>> method so that users whose browsers have no javascript can still > >>>>>>> select a date in a reasonable way. > >>>>>>> There is no longer an obnoxious ":date" field in the returned > >>>>>>> multiparameter values. > >>>>>>> Bundles now accept optional parameters. For the dynarch_calendar > >>>>>>> bundle, you can specify the color stylesheet, language and icon > >>>>>>> for > >>>>>>> your dynarch calendar. > >>>>>>> 12-hour time is handled in a novel way, so that the user enters > >>>>>>> a 12- > >>>>>>> hour time (e.g. 3 PM) and Rails can read it as if it''s a 24-hour > >>>>>>> time. > >>>>>>> Better documentation. > >>>>>>> Version 0.9 of bundled_resource now also includes a > >>>>>>> "stateful_form" > >>>>>>> bundle that makes it easier to store the open/closed states of > >>>>>>> form > >>>>>>> sections. This is particularly useful for AJAX forms that have > >>>>>>> hidden > >>>>>>> sections that the user can open up. When the form is submitted > >>>>>>> to the > >>>>>>> server and returned with an error, the form will retain its > >>>>>>> open/ > >>>>>>> closed states so that it''s just as the user expects it. > >>>>>>> > >>>>>>> == Download and Subversion => >>>>>>> > >>>>>>> TAR / GZIP: http://inquirylabs.com/downloads/ > >>>>>>> bundled_resource-0.9.tgz > >>>>>>> Subversion: svn://syncid.textdriven.com/svn/opensource/ > >>>>>>> bundled_resource/trunk > >>>>>>> > >>>>>>> > >>>>>>> [1] The permalink is http://blog.inquirylabs.com/2006/01/26/ > >>>>>>> bundled- > >>>>>>> resource-v-09-full-dynarch-calendar-support/ > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Posted via http://www.ruby-forum.com/. > >>>>>> _______________________________________________ > >>>>>> Rails mailing list > >>>>>> Rails@lists.rubyonrails.org > >>>>>> http://lists.rubyonrails.org/mailman/listinfo/rails > >>>>> > >>>>> _______________________________________________ > >>>>> Rails mailing list > >>>>> Rails@lists.rubyonrails.org > >>>>> http://lists.rubyonrails.org/mailman/listinfo/rails > >>>>> > >>>> _______________________________________________ > >>>> Rails mailing list > >>>> Rails@lists.rubyonrails.org > >>>> http://lists.rubyonrails.org/mailman/listinfo/rails > >>> > >>> _______________________________________________ > >>> Rails mailing list > >>> Rails@lists.rubyonrails.org > >>> http://lists.rubyonrails.org/mailman/listinfo/rails > >> > >> _______________________________________________ > >> Rails mailing list > >> Rails@lists.rubyonrails.org > >> http://lists.rubyonrails.org/mailman/listinfo/rails > >> > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Wed, 2006-03-01 at 09:58 +1100, David Mitchell wrote:> Thanks Duane, > > That was it - I had to put <%= define_javascript_functions %> in the > <head> section of my page, and then everything worked fine. > > Thanks also to everyone else who responded; this is a great mailing > list because of people like yourselves, willing to help out a guy > who''s struggling. I wish more lists were like this one. >---- don''t know what lists you been looking at but I know a bunch of them that are helpful. Craig