THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Transcript
PSquad33 my biggest concerns are making sure we don't bite off more than we can chew and that we keep WebWork... WebWork
jcarreira Have you looked at Cameron's stuff?
iroughley what were your thoughts on Camerons checkins?
PSquad33 i'm not interested in becoming a vehicle for distributing dojo
iroughley yes
jcarreira I wanted to talk to him about contributing his stuff back to dojo
PSquad33 all the javascript widget stuff sounds like it is getting a little too far away from webwork. but still, it is interesting
PSquad33 anyway, i'll be on and off
iroughley I like dojo as the transport, but as soon as you get too far into JS I am concerned abouot browser compatibility
jcarreira I like the idea of making the components dojo widgets, but I want the JSP tags to write out the dojo widgets... that way we can maintain server-side state
jcarreira yeah, that's a good reason to put it in dojo... more people using it = more compatibility testing
iroughley exactly
PSquad33 are we going to support dojo entirely, or will this be optional stuff? i just don't want to divert focus
PSquad33 maybe we should make an seperate project or something. do my concerns make sense?
jcarreira well, I think we should have an Ajax theme
iroughley I like using it as the transport, and the event stuff is good.
jcarreira I don't know... I think it's important to have rich widgets as part of the framework...
PSquad33 sure -- but we can't abandon our base either
jcarreira ...and they're going to do drag-n-drop, etc.
PSquad33 people still use the plain old XHTML theme
PSquad33 i want to keep the goals in sync
PSquad33 anyway, my big concern is that I feel a bit left out of the loop -- and if I do, our users defintiely will
iroughley I guess my underlying issue with the code that cameron added, was that it had no dependency with webwork
PSquad33 so you guys need to really hold my hand on this if you think this is the right direction to go
PSquad33 show me the vision in simple to understand terms
PSquad33 ian: exactly
PSquad33 ian: that is exactly my concern -- we're going to fragment the user base at this rate
jcarreira yeah.. I don't want to get into the biz of maintaining add-ons to dojo
iroughley it could be used with or without webwork, and then we are developing for someone else
jcarreira I wanted to talk to him about contributing the JS stuff back to dojo, and we just use it
jcarreira I've been trying to think through if we need the server-side events too
iroughley so then move in the direction that I think we are going - tag libs around the attributes for the dojo elements
jcarreira yep
iroughley so that we can link into server side state
jcarreira Should we just maintain UI widget dependencies on the client-side?
jcarreira or should we try to implement a real MVC style where the model changes cause the correct view components to update?
iroughley this is a urious question
iroughley i like loose dependencies on the client, via topics
iroughley so far, for what I am doing it works well
jcarreira so the UI components just know to listen to topics and refresh themselves?
iroughley yes
jcarreira in that case it can just be a UI component theme
iroughley the caveat is that the components have a known grnularity, that is understood by the developer
iroughley yes
jcarreira except for the extra JSP attributes
iroughley and changed per theme
jcarreira what do you mean about the granularity?
iroughley you have to know that a remote div (for example) might get a list from the server, or render a domain object
jcarreira I was thinking the remote div would just get HTML and set its innerHtml
iroughley so when you call that div to refresh itself you are doing work to obtain the information
jcarreira that way it's just like a ww:action tag...
iroughley yes
iroughley the action does the work
jcarreira and if you have it like this:
jcarreira <ww:remotediv action="foo"/>
jcarreira actually...
jcarreira this could just be a theme for the ww:action tag...
jcarreira ...except it's not a UI tag
iroughley true
jcarreira but it could wrap a ww:action tag and delegate calls to it
jcarreira but maybe that's limiting its reusability
jcarreira <ww:remotediv href="foo.action"><ww:action name="foo"/></ww:remotediv>
jcarreira the contents of the ww:remotediv would be the original content (no need for a separate call to load the content), then the href would be used when it refreshes
iroughley that's a good idea
iroughley i haven't had a chance to implement the initial content yet (as per your suggestion last week)
jcarreira what are the params to the remotediv tag?
iroughley so, i guess that the UI doesn't need to maintain dependencies on the client, just make calls via remote div's (or other components) and let the actions determine the state
jcarreira yeah
jcarreira but we need things like select boxes which can populate
|<-- PSquad33 has left efnet (Read error: Connection reset by peer)
iroughley is, url, updateFreq, loadingText, reloadingText, errortext, showErrorTransportText, topicName
jcarreira for example, if I'm shopping and I select a catalog, it should populate the product categories in a select list automatically
jcarreira ...I'd also like to be able to have a lazy-loading tree widget
iroughley i agree
jcarreira the loadingText can go away.. just make it the body enclosed by the tag
iroughley that was my plan
jcarreira we need a way to tell it to load immediately... then the default text would be there while it loads the first time
iroughley :)
iroughley my idea exactly
iroughley monday I hope it will be done
jcarreira cool
iroughley could the select tag and tree tag use topics to refresh state from the server
jcarreira what do you mean?
iroughley then use DWR or dojo to obtain JS to refresh themselves
jcarreira ah
-->| PSquad33 (~PSquad32@c-67-160-147-93.hsd1.or.comcast.net) has joined #webwork
PSquad33 back
PSquad33 sorry about that
PSquad33 you guys still talking about stuff
jcarreira but where do they call to get the stuff to refresh themselves?
PSquad33 ?
jcarreira yep
iroughley yeah
jcarreira you need to bind something to DWR to populate the list, right?
iroughley the data has to be sourced from somewhere originally, right?
iroughley yep
jcarreira yeah... originally it might be in the action
iroughley exactly
PSquad33 let me know when you guys are ready to talk strategy. i don't have much to add technically, but i want to make sure we are absolutely clear on our strategy and market perception.
jcarreira would we want to populate the data on the client?
iroughley what do you mean?
jcarreira pre-populate a data structure and select from there...
|<-- PSquad33 has left efnet (Remote host closed the connection)
iroughley personally I wouldn't - if you are using ajax the assumption is that the data may change, and should be refreshed from the server
iroughley that doesn;t mean that we shouldn't have a static tree widget
jcarreira I guess I don't know how DWR works... how do you tell it what to call? Can it load data from the session?
iroughley DWR (i think) makes a call to a method on a serverside object - like a spring BO
jcarreira can it access the session to get its data?
iroughley i would think that you could have it access a WW action, and return the session information from there
iroughley i haven't looked at it lately
jcarreira I'm asking Patrick... he keeps getting kicked off
iroughley do you want to try another IRC server?
jcarreira nah, it's his client
jcarreira he's got a cheesy shareware one for mac
iroughley ok - so if anyone changes the select list they update an element in the session - then the select list uses DWR to call an action with a list name (?) which obtains a refreshed (possibly) list from the session
jcarreira I was using an onChange() call... it uses bind() to call and set something into the session
iroughley that would work
jcarreira we need a way to make it easy for users to bind onChange to a call to the server
jcarreira You shouldn't have to write a JS function everytime
-->| PSquad32_ (~chatzilla@c-67-160-147-93.hsd1.or.comcast.net) has joined #webwork
PSquad32_ yo yo
PSquad32_ chatzilla to the rescue
jcarreira ok, Patrick was just explaining DWR to me
iroughley but it's more complex than that, as it might not be the same element - it may be a different one
iroughley ok
jcarreira no, it shouldn't change anything client-side
PSquad32_ so yeah, lemme know when you are ready to talk strategy. dojo doesn't seem to line up with what webwork is about at all, so i'm a bit worried
jcarreira it should make a call to the server, set some session state, then return and send a client-side topic message
iroughley ok - yes
jcarreira it's maybe a little more chatty, but it's simple to understand and model
jcarreira and very loosely coupled
iroughley could we set up each of the UI tags to define whether they send or update, and then wire it up for the users?
iroughley more chatty, but the calls are going to be very small
jcarreira what do you mean?
jcarreira I think each UI component should be able to be given a URL to hit with the new value onChange()
jcarreira and a topic to publish to
iroughley agreed
iroughley so that call will be small (not alot of data in the URL)
jcarreira and also have a topic to listen to that would load the value... so that would need a url to get the list
iroughley yes
iroughley and that call is going to be returning just the list, and not a complete HTML page - do the data being sent back to the client will be small
jcarreira yep.. but in what form does it return the list?
jcarreira ...patrick, we're almost done with the Js stuff....
iroughley innerHTML?
jcarreira what does it mean if you set the innerHtml of a select tag? what do you set it to?
iroughley it's easy and whatever is called on the server to get the data out of the session can format it to html
iroughley I would think that any tag can be gotten by id, and then html set in it
iroughley so <OPTION>one</OPTION> etc.
PSquad32_ i'm going to play a game of halo -- be back in a few :)
jcarreira yes, but what do you set into the innerHtml of a select tag to populate it? is it just the <options>?
iroughley i think so
iroughley haven't tried it, but it makes sense
jcarreira ok, so for the tree... it needs to get javascript back, probably, or some data structure... should we support both?
Fracture Hi
jcarreira Hi Fracture...
Fracture i'm going to read the log to catch up
iroughley i think that depends on the core tree widget that we use and augment for the implementation
jcarreira true... I've been playing with dtree for a while... it's pretty easy
jcarreira Fracture, I'm not sure who you are IRL...
iroughley do you think that returning JS or HTML would be easier with dtree?
jcarreira JS
iroughley i think that's fine then - the action/object that obtains the data from the session can modify it to JS to return to the browser
jcarreira This is how I add things to the tree:
jcarreira <ww:iterator value="categories">
jcarreira tree.add(<ww:property value="id"/>,<ww:property value="(parentCategory == null)?0:parentCategory.id"/>,'<ww:property value="name"/>','javascript:changeCategory(<ww:property value="id"/>);','<ww:property value="name"/>','_top','/img/folder.gif','/img/folderopen.gif');
jcarreira </ww:iterator>
jcarreira then you add it to the page like this:
jcarreira document.write(tree);
iroughley cool
iroughley we could even use JS for the select - just an implementation detail, as it will be hidden from teh end user
jcarreira but I think we can get to that later... I'm ok hardwiring this one together for now.. but we should make it easy to create components that send changes to the server to update server state and then send update events on topics
Fracture is Cameron :)
jcarreira ahh.. ok...
=-= Fracture is now known as Cameron-
jcarreira Cameron, let us know when you're caught up
Cameron- shall do .. half way there.
iroughley i would agree with that
iroughley while we are handwiring, we should also start thinking about a naming convention for the topics
jcarreira categoryChange, userChange, etc?
iroughley yes - I have been using topic_{html id}_event - i.e. topic_myRemoteDivId_refresh
iroughley but they can easily change
jcarreira I think we should make it easy to type and remember... users will end up needing to do some wiring themselves at some point
iroughley makes sense
iroughley on some of the elements i added a topic to publish to - perhaps I should go ahead and add this to them all
jcarreira where would we be defining topics?
iroughley at the moment I autowire some, and give the user the option of specifying them on some
jcarreira well, we should talk through that with Patrick... how we're going to position this Ajax stuff... if we're going to add attributes to the taglibs, etc.
jcarreira which are autowired?
jcarreira brb
iroughley from memory I think the autowired ones are - remotediv sends a "refesh", tab header sends a "tab selected"
iroughley remote div can specify a topic to listen to and refrsh itself - i think that might be the only one for now
Cameron- ok - I agree that these dojo widgets that I have created really belong in dojo - or a separate project. I was just demonstrating that rather than us write javascript code (that the ww components use) we write them as dojo widgets, and use the components to bind data to them. When using more interactive client controls - webwork more becomes a controller for marshaling data. I do think that we need to bundle a dojo build with w
iroughley oh - the remote link / <a href> is autowired to send a "refresh"
Cameron- and also allow our users to use a different profile build - if they meet our dependencies
PSquad32_ cameron: this whole dependency on dojo widgets is very un-webwork-ish
PSquad32_ i _really_ think it is not the right direction
Cameron- we depend on DRW, we depend on XmlHttpRequest..
Cameron- we have to have dependencies
PSquad32_ but we're depending on a framework
PSquad32_ the others are libraries
PSquad32_ dojo is a framework
PSquad32_ think about it from user's perspective. when they upgrade to 2.2, what are they going to see?
PSquad32_ what is the "webwork message"?
PSquad32_ what is our story? we can't have 4 different versions of the same story
jcarreira well, that's where we need to decide if this is a theme
jcarreira I think this is the Ajax theme
jcarreira and it requires dojo
jcarreira I think we bundle a dojo profile with the example app
PSquad32_ i think that is fine (a lot of this is marketing more than anything)
iroughley are there cases where you might needs to utilize multiple themes for a single compnent?
jcarreira yes
iroughley i.e. 2 different styles of lists or tabbed controls on the same page
iroughley so each of these would then need to be developed from teh core ajax theme
jcarreira sometimes I end up using the "simple" theme because the layout requires I can't put it in the table
jcarreira what do you mean?
iroughley it's late - i think i just confused myself :)
jcarreira what's our status with JSP 2?
jcarreira with JSP 2 you can just add more attributes without having to put them in the TLD, right?
PSquad32_ i am fine iwth requiring jsp 2
jcarreira I don't really know the features of JSP 2 :-)
jcarreira but requiring JSP 2 is requiring J2EE 1.4 and J2SE 1.4, right?
jcarreira which means no WebSphere 4.x or 5.0
PSquad32_ websphere 5 is JDK 1.4
jcarreira 5.1 is
iroughley if that is the case i would opt not to exclude those markets
PSquad32_ that's fine
PSquad32_ we don't need JSP 2 features
PSquad32_ ww:param works
PSquad32_ i have to run
PSquad32_ let's keep thinking about what the webwork story is -- how all this fits in
PSquad32_ we can't just say the old stuff doens't matter or isn't supported
Cameron- so Pat - what is the wework story ?
PSquad32_ well, i think we all need to work on that
PSquad32_ i'll draft up some thoughts -- maybe you guys can too
jcarreira ok, so if not JSP2, then we need to pull those attributes out and use ww:param to parameterize the tag for this specific theme
PSquad32_ my main concern is that you guys understand what i'm saying :)
PSquad32_ anyway, i have to run
PSquad32_ see ya
jcarreira later
Cameron- bye
iroughley later
jcarreira so if this is going to be a theme, we can't add theme-specific attributes
iroughley for the remote div that cameron added - right?
Cameron- you can - using ww:param no ?
jcarreira right, I mean attributes to the TLD
Cameron- you could probably add optional ones, and document them as 'only used for xxx theme'
jcarreira Hmm... could be.... as long as it's very clear... I don't want to be answering questions about why the topic isn't being used with the xhtml theme
Cameron- true
jcarreira speaking of which, does anyone know if someone actually build a real XHTML theme using div's and CSS instead of tables?
jcarreira built
iroughley no idea
Cameron- no idea
iroughley a while back i thought cloves and pat were talking about doing it
Cameron- yeah - I rememer hearing that.
iroughley so the plan is to move forward with a dojo/ajax theme?
jcarreira yes
jcarreira who wants to take what?
Cameron- with regards to your 'topics' ... are they for use client side .. or do these events get routed to an action too ?
jcarreira Cameron, you're going to talk to the dojo guys about contributing the remote div, remote link, and remote submit stuff to dojo?
jcarreira they're the dojo.event.Topic stuff that lets you do publish/subscribe in JS
Cameron- yep - i'll do that.
iroughley we will also require theme specific tags then, right?
Cameron- so you use topics for inter widget communication ?
iroughley remote div for example
jcarreira I built it as a wrapper around their event stuff
iroughley yes - mainly for server side refreshes at the moment
jcarreira I think let's keep the theme specific attributes for now
jcarreira the idea is for a component to update its server state then publish a message on a topic
Cameron- so something emits an event, a widget is triggered, which then refreshes itself ?
Cameron- sure
jcarreira yep, the developer specifies with the tags which topic(s) a component listens to to refresh itself
iroughley or parts of itself - like the drop down list elements
jcarreira and which topic a component publishes on when it is changed
jcarreira so they are loosely coupled and the developer specifies which thing listens to the others
Cameron- cool.
jcarreira so about dojo and source
iroughley so - there are 3 parts as i see it - 1. the dojo UI widgets, 2. the events/topics, and 3. the WW tag/component that combines them all
Cameron- yep
iroughley go ahead jason
jcarreira should we just bundle the __package__.js?
Cameron- we also need the other 'non bundled' files.. like html templates, css files and other widget resources (gif/jpg)
jcarreira yeah, the tags generate JS to use the dojo widgets and JS to wire them to topics
jcarreira ok
jcarreira where do those come from?
Cameron- I setup an ant target dojo-profile that causes dojo to build a __package__.js and copy it and other non bundled resources into the os/static/dojo package
Cameron- where do those come from ? dunno what you mean
jcarreira Well, I don't know about bundling the sources to dojo into webwork's CVS
jcarreira I think we should just bundle the final built product, like we do with other libraries
iroughley also, if they are in webwork.static, can the end user override the images easily if they wanted?
Cameron- that depends on how the widet is authored
Cameron- authored
jcarreira how does one specify the images to be used?
jcarreira can it be done so that the template could be edited to change where they come from?
Cameron- the widget can take a img= attribute and use it in the building of the rendered widget.
iroughley ok - so it doesn't need to be in ww.static
jcarreira well, the defaults can be
Cameron- doesn't have to be.. however .. defaults may be packaged there
iroughley ok - makes sense
jcarreira ok, so the order of things:
jcarreira 1) Cameron, you're going to try to get this stuff into dojo
jcarreira 2) we build a profiles of dojo with the widgets
jcarreira 3) we edit the JSP templates to use the dojo widgets
jcarreira sound good?
jcarreira anything i'm missing?
iroughley sounds good
Cameron- with the remote div.. why do we need a jsp template ?
jcarreira because we want to wire it to topics
Cameron- why not have a <dojo:topic> widget ?
jcarreira and it can take the body contents as the default content of the div
Cameron- the body content can be done <dojo:remotediv attribs...><ww:action name='foo'/></dojo:remotediv>
jcarreira what would the dojo:topic do?
Cameron- the dojo:topic would 'install' the topic 'bus' into the page
jcarreira well, I'd like to keep things consistent... using ww: tags and auto-wiring them to topics
iroughley can th edojo:topic tag specify the topic to listen to and the topic to publish to when an event ocurrs?
iroughley it's also going to be more code for developers to type
jcarreira <ww:remotediv listenTopic="itemSelected"> creates JS to wire the div to refresh when it gets a message on that topic
jcarreira yeah, we want to make this dead-simple
Cameron- dojo:remotediv listenTopic='itemSelected'> can do the same thing.. without a jsp template
jcarreira ...and it doesn't hurt to wrap dojo in case something else comes along and we replace the JS library
Cameron- I think we only need to use a jsp tag when we need to access action context from the tag
jcarreira I don't want to make users know anything about dojo
Cameron- ok.. well. I think we have two different approaches.
iroughley if we don't wrap it, it won't really be a theme - wil it?
jcarreira yeah, the JSP template can just call the dojo stuff, so you can just use the dojo stuff directly, too
iroughley it will be something else to use with ww
Cameron- ok
jcarreira well... maybe we should just make this a ww:div tag
iroughley makes sense
jcarreira and in the Ajax theme it can become a remote div
iroughley then we also need a <ww:a>
iroughley :)
jcarreira yeah... we should do that
jcarreira it can use the URLTag code
Cameron- sounds good
jcarreira ok, Ian, do you want to take those?
iroughley sure
jcarreira cool
iroughley we also need dojo components for the existing elements - remote div, remote a link, tabbed panel - right?
jcarreira yeah... not sure how hard it is to do the tabbed panel... that's a more complicated one
iroughley tonight we also talked about a select list and tree element
iroughley it might be easy - just use <ww:div> and it will just not update - events will be the only issue
jcarreira ...and I still want them to build a nice menuing system :-)
iroughley the only other thing I was thinking about is a paginated list
jcarreira let's get the ones we've got now using the new architecture
jcarreira JSP tag -> template -> dojo widget
iroughley cameron - you up for building the dojo components?
Cameron- yeah
jcarreira ok, I'll fill Patrick in with where we're heading and maybe we can schedule another chat to talk about the WebWork message, etc
Cameron- ok
iroughley ok - then I will start on the remote div tag/template from teh dojo component next monday
Cameron- we need a wiki page to list the ajax theme components
Cameron- (so I know what to build)
iroughley let me know as new ones come down the pipe
iroughley the current tutorial list all the ones i've done - localhost/webwork/tutorial/ajax/...