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/...