Forum: Ruby on Rails [ANN] bundled_resource v.0.9

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Duane J. (Guest)
on 2006-01-27 06:16
(Received via mailing list)
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/
Richard L. (Guest)
on 2006-01-27 14:07
(Received via mailing list)
Duane J. 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
Duane J. (Guest)
on 2006-01-27 17:59
(Received via mailing list)
On Jan 27, 2006, at 5:09 AM, Richard L. wrote:

> 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 J.
(canadaduane)
http://blog.inquirylabs.com/
Steve R. (Guest)
on 2006-01-31 01:00
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 R.


Duane J. 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/
Duane J. (Guest)
on 2006-02-02 06:23
(Received via mailing list)
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
David M. (Guest)
on 2006-02-28 05:26
(Received via mailing list)
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.
Duane J. (Guest)
on 2006-02-28 06:31
(Received via mailing list)
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 J.
(canadaduane)
http://blog.inquirylabs.com/
David M. (Guest)
on 2006-02-28 07:33
(Received via mailing list)
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.
Tom M. (Guest)
on 2006-02-28 08:38
(Received via mailing list)
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 M.
David M. (Guest)
on 2006-02-28 09:53
(Received via mailing list)
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.
Tom M. (Guest)
on 2006-02-28 10:06
(Received via mailing list)
Does your markup validate?

--
-- Tom M.
David M. (Guest)
on 2006-02-28 11:57
(Received via mailing list)
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.
Tom M. (Guest)
on 2006-02-28 12:56
(Received via mailing list)
On Feb 28, 2006, at 1:55 AM, David M. 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+Val...

And, I'm referencng my own test_helper.rb based routines, which are
in a large part developed by "Scott R." <removed_email_address@domain.invalid>

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 M.
David M. (Guest)
on 2006-02-28 13:18
(Received via mailing list)
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.
Craig W. (Guest)
on 2006-02-28 15:27
(Received via mailing list)
On Tue, 2006-02-28 at 22:15 +1100, David M. wrote:
> 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
D. Taylor S. (Guest)
on 2006-02-28 16:37
(Received via mailing list)
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 S.,
Reality Technician
Duane J. (Guest)
on 2006-02-28 18:28
(Received via mailing list)
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
Duane J. (Guest)
on 2006-02-28 18:35
(Received via mailing list)
On Feb 28, 2006, at 7:36 AM, D. Taylor S. wrote:

>
> 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 S.,
> 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 J.
(canadaduane)
http://blog.inquirylabs.com/
Ben M. (Guest)
on 2006-02-28 18:41
(Received via mailing list)
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 M. (Guest)
on 2006-03-01 00:58
(Received via mailing list)
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.
Craig W. (Guest)
on 2006-03-01 01:59
(Received via mailing list)
On Wed, 2006-03-01 at 09:58 +1100, David M. 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
This topic is locked and can not be replied to.