Hopbot log for 2007-11-26 - Helma IRC channel: #helma on irc.freenode.net

2007-11-26:

[8:10] <zumbrunn> philmaker, regarding jquery etc and a server-side dom...
[8:10] <zumbrunn> http://helma.org/pipermail/helma-user/2007-July/007070.html
[8:11] <philmaker> I think I had seen something like that - sounds really neat to me
[8:11] <philmaker> thanks
[8:12] <zumbrunn> yes, at the same time though, the dom is the "messier" part of the client-side javascript environment
[8:13] <zumbrunn> (aside from browser incompatibilities)
[8:13] <zumbrunn> so, I'm not sure if bringing that to the server-side is really an "advancement"
[8:13] <philmaker> a few weeks ago, I started a thread on ExtJS about JS on the server. Somebody replied to my post a little offtopic - but I htink he was trying to get ExtJS working on the server.
[8:14] <philmaker> Now that sounds like a really excellent plan to me
[8:14] <philmaker> Learn one or two UI frameworks and you can use them on the client or server
[8:14] <zumbrunn> yes, the advantage is clear
[8:15] <zumbrunn> and it actually already works
[8:15] <zumbrunn> at least to some extent
[8:15] <philmaker> I have long preferred component based renders n the server side and not many frameworks provide it
[8:15] <zumbrunn> (like I mentioned in that thread)
[8:15] <philmaker> perhsp some examples that approach this are: wingsframework, clickframework, wicket, zk
[8:16] <zumbrunn> e4x is the candidate for an alternative approach
[8:17] <philmaker> Rails has the whole idea: convention of configuration. I think it is conventional that every page that is requested is going to need rendering or some sort of skin.
[8:17] <zumbrunn> but for now, you wouldn't get the advantage of having the same environment on both client and server side
[8:17] <zumbrunn> right
[8:17] <philmaker> So that's why to me having components that know how to render themselves by default from the server sound cool to me.
[8:19] <philmaker> Actually, I think it would be more conventional if one did not have to create skins - only need to create components which know how to render themselves by default but can be tailored.
[8:19] <philmaker> Just what I'd like to see more of someday - noone wlse may care.
[8:20] <zumbrunn> the question is how intelligent the components should be
[8:20] <philmaker> or really, how statefully persistent they should be?
[8:21] <philmaker> compoents for rendeing alone or should that maintain state?
[8:21] <zumbrunn> why would you need a server-side dom for any of that, though
[8:22] <zumbrunn> the components gan do some of their magic on the client side and some on the server side
[8:22] <zumbrunn> the two don't really need to mirror/duplicate each other
[8:23] <philmaker> I guess my primary motivation is really that I hate working with templates of html - I guess wish there were components which had default renderers which you could later tweak.
[8:23] <zumbrunn> that would just be an additional feature, not a requirement
[8:24] <zumbrunn> you mean going as far as having no html anywhere
[8:24] <zumbrunn> all of it being generated through code
[8:24] <zumbrunn> ?
[8:24] <philmaker> pretty much
[8:24] <philmaker> you still have access to html but don't need to write it
[8:25] <philmaker> for example: Qooxdoo and ExtJS require no html
[8:25] <zumbrunn> yes, but if you use ExtJS, for example, you don't need to produce the html on the server-side anyway
[8:26] <philmaker> really: being able to get rid of html pretty much requires layout managers: which both ExtJS and Qooxdoo have.
[8:26] <zumbrunn> your components on the server-side just create ExtJs code
[8:26] <philmaker> Re: yes, but if you use ExtJS, for example, you don't need to produce the html on the server-side anyway (but what if you wanted to)
[8:27] <philmaker> My point really is: html = assembly language
[8:27] <zumbrunn> that's where e4x might come in
[8:28] <philmaker> Today, I don't use assembly language
[8:28] <philmaker> I do need to look at e4x more
[8:31] <zumbrunn> e4x rocks, in my opinion
[8:34] <philmaker> I know there's an topic about this but...
[8:34] <philmaker> e4x works in Helma 1.6 or I need a special build?
[8:35] <philmaker> Or Rhino needed some fixed - I can't remember
[8:36] <philmaker> maybe a little e4x example/tutorial would be neat too
[8:37] <zumbrunn> the rhino.jar in the helma 1.6 build contained a e4x related bug, yes
[8:37] <zumbrunn> http://zumbrunn.com/mochazone/Rhino+1.6R6+with+E4X+fix+and+patches+for+Helma/
[8:38] <philmaker> Your revised reference docs look very stlyin
[8:38] <zumbrunn> http://zumbrunn.com/mochazone/I+love+E4X/
[8:39] <zumbrunn> the new reference docs still needs some tweaking, though
[8:39] <zumbrunn> for example, helma.Url is currently missing in action
[8:39] <philmaker> I'm working on getting a new host soon because I'm currently w/o hosting. I had been using a Java host called mmaweb - they were really nice but I do like the VPS better
[8:39] <philmaker> stylin'
[8:40] <philmaker> nice style
[8:40] <philmaker> ;-)
[8:40] <zumbrunn> yeah, got it the first time ;-)
[8:40] <philmaker> lol
[18:03] <hypersmil> does anyone use the helma rss feed (http://dev.helma.org/updates/main.rss)?
[19:38] <zumbrunn> depends on what you mean with "use", yes

 

 

In the channel now:

Logs by date: