From mneumann at ntecs.de  Sun Apr  3 07:32:31 2005
From: mneumann at ntecs.de (Michael Neumann)
Date: Sun Apr  3 07:27:23 2005
Subject: [Wee-talk] Alive?
In-Reply-To: <Pine.NEB.4.62.0503302123120.20545@angelic-vtfw.cvpn.cynic.net>
References: <Pine.NEB.4.62.0503301150560.20545@angelic-vtfw.cvpn.cynic.net>
	<200503301144.08402.mneumann@ntecs.de>
	<Pine.NEB.4.62.0503302123120.20545@angelic-vtfw.cvpn.cynic.net>
Message-ID: <200504031332.31258.mneumann@ntecs.de>

Am Mittwoch 30 M?rz 2005 14:36 schrieb Curt Sampson:
> On Wed, 30 Mar 2005, Michael Neumann wrote:
> > Yes of course, it's alive. But I don't have much Wee questions ;-)
>
> Do you mind a few? How about a zillion or so?
>
> Let's start with a documentation bug. At the beginning of
> lib/wee/adaptors/webrick.rb:
>
>      # Example of usage:
>      #
>      #   require 'wee/adaptors/webrick'
>      #   s = WEBrick::HTTPServer.new(:Port => 2000)
>      #   s.mount '/app', Wee::WEBrickAdaptor, application
>
> That last line should read
>
>      #   s.mount '/app', Wee::WEBrickAdaptor, '/app', application

Sorry for the late response. 

Fixed it.

> But the adapter already ought to be able to get the app path from
> WEBrick's HttpRequest.path_info method.

Right. But there are situations where do want to use a different path then 
what is given in HttpRequest.path_info. Imagine you pass requests via 
mod_proxy though the Apache to a Wee Webrick adaptor. The Wee application is 
mounted on http://hostname:2000/app, but it is accessible as 
http://hostname:80/wee/app from the main Apache. So you need to use /wee/app 
as application path in all URL instead of /app, otherwise this will no longer 
work.

> Are patches like this useful? Just going through the code, I feel as
> if I see a lot of stuff that I could simplify, without losing any
> functionality.

Yeah, any patch is useful as well as questions are always welcome. I'm happy 
for any suggestion that makes Wee more simple.

> The biggest problem is that I feel I would need to sit down and pair
> program with someone who knows Wee a lot better than me to be able to be
> effective at this....

I'm miles away from you, so only remote pair programming would work ;-)

Regards,

  Michael

From mneumann at ntecs.de  Mon Apr  4 13:04:36 2005
From: mneumann at ntecs.de (Michael Neumann)
Date: Mon Apr  4 12:59:25 2005
Subject: [Wee-talk] [ANN] Wee 0.8.0
Message-ID: <200504041904.36814.mneumann@ntecs.de>

Hi,

Wee 0.8.0 is out. Have fun!

Major changes are:

  * Ajax support (live updates). See examples/ajax/ajax.rb.

  * FastCGI adaptor (working but not fully tested)

  * Fixed bug in callback processing.

For example, you can update a field with Ajax like this:

  def render
    r.div.id('field')
    r.anchor.onclick_update('field') { update_field }.with('Click here')
  end

  def update_field
    send_render_response {
      r.text "Live update works!"
    }
  end

More? http://rubyforge.org/projects/wee

Regards,

  Michael
From mneumann at ntecs.de  Wed Apr  6 07:45:20 2005
From: mneumann at ntecs.de (Michael Neumann)
Date: Wed Apr  6 07:40:03 2005
Subject: [Wee-talk] Re: [ANN] Wee 0.8.0
In-Reply-To: <POI4e.37061$1H3.15984@tornado.texas.rr.com>
References: <200504041904.36814.mneumann@ntecs.de>
	<POI4e.37061$1H3.15984@tornado.texas.rr.com>
Message-ID: <200504061345.20727.mneumann@ntecs.de>

Am Mittwoch 06 April 2005 05:39 schrieb itsme213:
> "Michael Neumann" <mneumann@ntecs.de> wrote in message
>
> > Wee 0.8.0 is out. Have fun!
>
> How does one update multiple DOM nodes in a single liveUpdate?

Good question. No problem from the Wee side, but I am not good enough in 
Javascript to implement this. What I thought is, that Wee would generate a 
document like:

  <root>
    <div id="id1">  .... content .... </div>
    <div id="id2"> ..... content .... </div>
  </root>

This would update the DOM nodes id1 and id2 with the content.

Anyone willing to hack this in javascript?

Regards,

  Michael
From james.britt at gmail.com  Thu Apr  7 19:06:22 2005
From: james.britt at gmail.com (James Britt)
Date: Thu Apr  7 19:07:44 2005
Subject: [Wee-talk] Re: [ANN] Wee 0.8.0
In-Reply-To: <200504061345.20727.mneumann@ntecs.de>
References: <200504041904.36814.mneumann@ntecs.de>	<POI4e.37061$1H3.15984@tornado.texas.rr.com>
	<200504061345.20727.mneumann@ntecs.de>
Message-ID: <4255BCEE.3060107@gmail.com>

Michael Neumann wrote:
> Am Mittwoch 06 April 2005 05:39 schrieb itsme213:
> 
>>"Michael Neumann" <mneumann@ntecs.de> wrote in message
>>
>>
>>>Wee 0.8.0 is out. Have fun!
>>
>>How does one update multiple DOM nodes in a single liveUpdate?
> 
> 
> Good question. No problem from the Wee side, but I am not good enough in 
> Javascript to implement this. What I thought is, that Wee would generate a 
> document like:
> 
>   <root>
>     <div id="id1">  .... content .... </div>
>     <div id="id2"> ..... content .... </div>
>   </root>
> 
> This would update the DOM nodes id1 and id2 with the content.
> 
> Anyone willing to hack this in javascript?

Having multiple elements with the same ID is bad.

But: Here's an example of taking a chunk of XML and selecting content by 
ID and updating.

Please note that I've only recently started lurking here, so I don;t 
really have much idea of how liveUpdate is to work, but one should be 
able to get some ideas from this;

<html>
  <head>
   <meta id='cache' />
   <script type='text/javascript'>
    var id_prefix  = "wee_"
    function get_some_xml(){
       var xml = "<div id='wee_id1'>foo</div>"
          xml += "<div id='wee_id2'><em>Two</em></div>"
       return xml
     }

     function set_xml(){
       var el = document.getElementById( 'cache' )
       el.innerHTML =  get_some_xml()
    }

    function update() {
        set_xml()
        var cache = document.getElementById( 'cache' )
        for ( var x = 1; x < cache.childNodes.length; x++ ) {
          var attr_id =  cache.childNodes[x].attributes['id']
          var src_id =  attr_id.value.split( id_prefix )[1]
          var src_el =  document.getElementById( src_id ) 

          src_el.innerHTML = cache.childNodes[x].innerHTML
        }
      }


   </script>
  </head>
  <body onclick='update()'>
   <h1 id='id2'>Test</h1>
   <p id='id1'></p>
  </body>
</html>

Load in browser,`click on page.

Bascially, something fetches the chunk of XML and stashes it in a
holding element.  Then the code selects that chache and loops over the 
child nodes, grabbing innerHTML from one place and assigning it 
someplace else.

I had issues with this in IE6, but I'm going to guess everyone here is 
running Firefox anyway, so for demo purposes this should do.

James

From itsme213 at hotmail.com  Thu Apr  7 20:53:08 2005
From: itsme213 at hotmail.com (itsme213)
Date: Thu Apr  7 20:47:49 2005
Subject: [Wee-talk] Re: [ANN] Wee 0.8.0
References: <200504041904.36814.mneumann@ntecs.de>	<POI4e.37061$1H3.15984@tornado.texas.rr.com><200504061345.20727.mneumann@ntecs.de>
	<4255BCEE.3060107@gmail.com>
Message-ID: <BAY101-DAV12231DF33322DA00AD6CA7993F0@phx.gbl>

----- Original Message ----- 

There is a Javascript method on Node:

   replaceChild(newChild, oldChild)

So perhaps (not tested):

    old_node = document.getElementById (theId);
    old_node.parentNode.replaceChild (new_node, old_node);

I don't know what Wee delivers to the client end. If it is a nice
DOM-subtree object then:

for (var i = 0; i < new_tree.childNodes.length; i++) {
  new_node = new_tree.childNodes[i];
  theId = new_node.attributes['id'];
  old_node = document.getElementById (theId);
  old_node.parentNode.replaceChild (new_node, old_node);
}

If it is an XHTML string then maybe James' trick of innerHTML can be used
first:

  new_tree = document.getElementById( 'cache' );
  new_tree.innerHTML =  the_xhtml_string;
  for (var i = 0; ..... )



> From: "James Britt" <james.britt@gmail.com>

> Having multiple elements with the same ID is bad.
>
> But: Here's an example of taking a chunk of XML and selecting content by
> ID and updating.
>
> Please note that I've only recently started lurking here, so I don;t
> really have much idea of how liveUpdate is to work, but one should be
> able to get some ideas from this;
>
> <html>
>   <head>
>    <meta id='cache' />
>    <script type='text/javascript'>
>     var id_prefix  = "wee_"
>     function get_some_xml(){
>        var xml = "<div id='wee_id1'>foo</div>"
>           xml += "<div id='wee_id2'><em>Two</em></div>"
>        return xml
>      }
>
>      function set_xml(){
>        var el = document.getElementById( 'cache' )
>        el.innerHTML =  get_some_xml()
>     }
>
>     function update() {
>         set_xml()
>         var cache = document.getElementById( 'cache' )
>         for ( var x = 1; x < cache.childNodes.length; x++ ) {
>           var attr_id =  cache.childNodes[x].attributes['id']
>           var src_id =  attr_id.value.split( id_prefix )[1]
>           var src_el =  document.getElementById( src_id )
>
>           src_el.innerHTML = cache.childNodes[x].innerHTML
>         }
>       }
>
>
>    </script>
>   </head>
>   <body onclick='update()'>
>    <h1 id='id2'>Test</h1>
>    <p id='id1'></p>
>   </body>
> </html>
>
From james.britt at gmail.com  Thu Apr  7 22:27:35 2005
From: james.britt at gmail.com (James Britt)
Date: Thu Apr  7 22:22:31 2005
Subject: [Wee-talk] Re: [ANN] Wee 0.8.0
In-Reply-To: <BAY101-DAV12231DF33322DA00AD6CA7993F0@phx.gbl>
References: <200504041904.36814.mneumann@ntecs.de>	<POI4e.37061$1H3.15984@tornado.texas.rr.com><200504061345.20727.mneumann@ntecs.de>	<4255BCEE.3060107@gmail.com>
	<BAY101-DAV12231DF33322DA00AD6CA7993F0@phx.gbl>
Message-ID: <d34pv7$10e$1@sea.gmane.org>

itsme213 wrote:
> ...
> I don't know what Wee delivers to the client end. If it is a nice
> DOM-subtree object then:


This is where something like JSON comes in handy, because you can easily 
package up structured data in a JavaScript-friendly way.  It is much 
easier to iterate over an array, or pull specific sub-structures from a 
hash, then to play DOM tricks.



James

From james.britt at gmail.com  Thu Apr  7 19:06:22 2005
From: james.britt at gmail.com (James Britt)
Date: Fri Apr  8 06:39:22 2005
Subject: [Wee-talk] Re: [ANN] Wee 0.8.0
In-Reply-To: <200504061345.20727.mneumann@ntecs.de>
References: <200504041904.36814.mneumann@ntecs.de>	<POI4e.37061$1H3.15984@tornado.texas.rr.com>
	<200504061345.20727.mneumann@ntecs.de>
Message-ID: <4255BCEE.3060107@gmail.com>

Michael Neumann wrote:
> Am Mittwoch 06 April 2005 05:39 schrieb itsme213:
> 
>>"Michael Neumann" <mneumann@ntecs.de> wrote in message
>>
>>
>>>Wee 0.8.0 is out. Have fun!
>>
>>How does one update multiple DOM nodes in a single liveUpdate?
> 
> 
> Good question. No problem from the Wee side, but I am not good enough in 
> Javascript to implement this. What I thought is, that Wee would generate a 
> document like:
> 
>   <root>
>     <div id="id1">  .... content .... </div>
>     <div id="id2"> ..... content .... </div>
>   </root>
> 
> This would update the DOM nodes id1 and id2 with the content.
> 
> Anyone willing to hack this in javascript?

Having multiple elements with the same ID is bad.

But: Here's an example of taking a chunk of XML and selecting content by 
ID and updating.

Please note that I've only recently started lurking here, so I don;t 
really have much idea of how liveUpdate is to work, but one should be 
able to get some ideas from this;

<html>
  <head>
   <meta id='cache' />
   <script type='text/javascript'>
    var id_prefix  = "wee_"
    function get_some_xml(){
       var xml = "<div id='wee_id1'>foo</div>"
          xml += "<div id='wee_id2'><em>Two</em></div>"
       return xml
     }

     function set_xml(){
       var el = document.getElementById( 'cache' )
       el.innerHTML =  get_some_xml()
    }

    function update() {
        set_xml()
        var cache = document.getElementById( 'cache' )
        for ( var x = 1; x < cache.childNodes.length; x++ ) {
          var attr_id =  cache.childNodes[x].attributes['id']
          var src_id =  attr_id.value.split( id_prefix )[1]
          var src_el =  document.getElementById( src_id ) 

          src_el.innerHTML = cache.childNodes[x].innerHTML
        }
      }


   </script>
  </head>
  <body onclick='update()'>
   <h1 id='id2'>Test</h1>
   <p id='id1'></p>
  </body>
</html>

Load in browser,`click on page.

Bascially, something fetches the chunk of XML and stashes it in a
holding element.  Then the code selects that chache and loops over the 
child nodes, grabbing innerHTML from one place and assigning it 
someplace else.

I had issues with this in IE6, but I'm going to guess everyone here is 
running Firefox anyway, so for demo purposes this should do.

James

From Aleksi.Niemela at cs.helsinki.fi  Thu Apr 28 13:57:22 2005
From: Aleksi.Niemela at cs.helsinki.fi (Aleksi Niemela)
Date: Thu Apr 28 13:51:26 2005
Subject: [Wee-talk] How to serve out resources in 0.8.0?
Message-ID: <42712402.1060809@cs.helsinki.fi>

I have to serve a static image (perhaps scale it down before sending) to 
logged in users. I thought to do it like examples/draw.rb does it. 
(Great example, btw. This is exactly what's needed to give out some idea 
how to use Wee in interesting context.) So my code is along these lines:

    ctx = r.context
    ctx = ctx.context
    img_data = File.open(physical_image.fname).read
    resource_handler = Wee::ResourceHandler.new(img_data, 'image/png')
    img_id = ctx.handler_registry.handler_id_for_resource(resource_handler)
    img_url = ctx.application.gen_resource_url(ctx.session_id, 
ctx.page_id, img_id)

    r.anchor.action(:show_images).with do
        r.image.src(img_url)
    end

But, there's a small problem. It doesn't run. Actually the example 
doesn't work either. Michael added:

    raise "this example does not work with the current version of Wee"

in the beginning of the code running up this example. Current version 
being 0.8.0. So what to do? What's the right way to serve out an image?

    - Aleksi

From mneumann at ntecs.de  Fri Apr 29 17:28:28 2005
From: mneumann at ntecs.de (Michael Neumann)
Date: Fri Apr 29 17:22:29 2005
Subject: [Wee-talk] How to serve out resources in 0.8.0?
In-Reply-To: <42712402.1060809@cs.helsinki.fi>
References: <42712402.1060809@cs.helsinki.fi>
Message-ID: <200504292328.29237.mneumann@ntecs.de>

Hi Aleksi,

Am Thursday 28 April 2005 19:57 schrieb Aleksi Niemela:
> I have to serve a static image (perhaps scale it down before sending) to
> logged in users. I thought to do it like examples/draw.rb does it.
> (Great example, btw. This is exactly what's needed to give out some idea
> how to use Wee in interesting context.) So my code is along these lines:
>
>     ctx = r.context
>     ctx = ctx.context
>     img_data = File.open(physical_image.fname).read
>     resource_handler = Wee::ResourceHandler.new(img_data, 'image/png')
>     img_id = ctx.handler_registry.handler_id_for_resource(resource_handler)
>     img_url = ctx.application.gen_resource_url(ctx.session_id,
> ctx.page_id, img_id)
>
>     r.anchor.action(:show_images).with do
>         r.image.src(img_url)
>     end
>
> But, there's a small problem. It doesn't run. Actually the example
> doesn't work either. Michael added:
>
>     raise "this example does not work with the current version of Wee"
>
> in the beginning of the code running up this example. Current version
> being 0.8.0. So what to do? What's the right way to serve out an image?

It's not yet implemented, but you could use a RequestHandler for now. Here an 
example that demonstrates this:

#######################################
require 'rubygems'
require 'wee'
require 'wee/adaptors/webrick' 
require 'wee/utils'

class Wee::ResourceHandler < Wee::RequestHandler
  def initialize(mime_type, content)
    super()
    @response = Wee::GenericResponse.new(mime_type, content)
  end

  def handle_request(context)
    super
    context.response = @response 
  end
end

class Wee::Application

  def insert_new_request_handler(request_handler)
    @mutex.synchronize {
      if @max_request_handlers != nil and @request_handlers.size >= 
@max_request_handlers
        # limit reached -> remove non-alive handlers...
        garbage_collect_handlers()

        # ...and test again
        if @request_handlers.size >= @max_request_handlers
          # TODO: show a custom error message
          raise "maximum number of request-handlers reached" 
        end
      end

      request_handler.id = unique_request_handler_id()
      request_handler.application = self
      @request_handlers[request_handler.id] = request_handler
    }
  end

end

class HelloWorld < Wee::Component
  def initialize
    super
    add_decoration(Wee::PageDecoration.new("Hello World"))
  end

  def render
    r.h1 "Hello World from Wee!"

    res = Wee::ResourceHandler.new('text/plain', 'blah blah blah')
    session.application.insert_new_request_handler(res)
    url = session.current_context.request.build_url(:request_handler_id => 
res.id, :page_id => nil, :info => nil)
    r.anchor.url(url).with('test')
  end
end

Wee::WEBrickAdaptor.register('/app' => Wee::Utils.app_for(HelloWorld)).start 
#############################################

Use a different mime_type instead of text/plain to serve an image. One big 
problem with the above code is, that it generates lots of request handlers. 
You should keep a hash of (mime_type, content) pairs as key, and avoid 
creating a new resource handler if the same (mime_type, content) pair already 
exists (this is how Seaside handles this).

Best is to have generate the md5 checksum of mime_type + content and use this 
as the key of a hash. The value of this hash would be the id of the request 
handler. Before you create a new one and call "insert_new_request_handler", 
check whether one already exists and reuse it.

Of course this hash keeps growing, so you should garbage collect it from time 
to time (that's little bit more tricky). Furthermore, you should reset the 
@last_access, to avoid that a reused request handler will time out to early 
(as the last_access is reused too).

Hope this helps. Maybe you can work something out. I'd be happy to include 
this in Wee ;-)

Regards,

  Michael