You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Julian Wood <wo...@ucalgary.ca> on 2007/02/09 19:05:10 UTC
Best strategy?
I'm working on taking this dhtml component here:
http://www.dhtmlgoodies.com/scripts/dhtmlgoodies-week-planner/
dhtmlgoodies-week-planner.html
and moving it into tapestry. It is heavy on javascript, AJAX and
somewhat less so on PHP. The javascript has many event hooks which
fire off AJAX requests to it's PHP backend.
My question is, what is the best strategy for moving to Tapestry?
I think the quickest and dirtiest solution is to create an engine
service for each of the AJAX calls, which replicate what the PHP does
in it's current incarnation. This does feel like the wrong way to do
it though, especially since in each service, I will need to add
state, while leaving the page's .java virtually empty. I'll also need
to put in raw URL's to the AJAX services, directly inside the
javascript.
So, knowing there must be a better way, I've been trying to figure
out how I can leverage the new stuff in 4.1 to do the job. The
javascript events in the planner are not straightforward - they are
calculated, and if necessary, an AJAX call is made. I'm not sure if
an EventListener can be made to monitor a complex event like that, or
if you can make a custom event to which an EventListener can listen.
So if I can dip into specifics, I know I can get the planner to load
all the "appointments" for a week pretty easily. But how to deal with
an appointment move? A resize (change in duration)? A delete? A
double click for an edit? Each of these has the additional problem
that they can be made on the fly, and there can be many of them. How
much of this can be moved in to a @Script? I'm of course aiming to
have each of the listener impl methods in my Planner class, backing
Planner.page and Planner.html, which will have the planner from
dhtmlgoodies inside.
So does anyone have any suggestions on which road to go down? I know
my quick and dirty will work, but I'm not sure if this second
approach will work, nor how much time it will take, but it seems like
it is closer to "the right way to do it". What is the right way?
Thanks,
J
--
Julian Wood <wo...@ucalgary.ca>
Software Engineer
Teaching & Learning Centre
University of Calgary
http://tlc.ucalgary.ca
Re: Best strategy?
Posted by Julian Wood <wo...@ucalgary.ca>.
Thanks Matt, for that insightful response.
I have decided after all to go with the XTile component. I guess I
had been leaning towards using EventListener, since that seemed the
way of the future, and a way to consolidate all the different AJAX
approaches out there. I find it interesting that your refer to it as
cruft :-) With XTile, the logic is fairly obvious, and thus
maintainable, and the porting is quite easy, requiring only minimal
modifications to the existing javascript, so it seems like the best
solution in this case.
Thanks again,
J
On 13-Feb-07, at 10:44 PM, Matt Brock wrote:
>
> That's a very nice little widget there.
>
> This would be very easy to move to the Tapestry world. I guess it
> would
> really depend on how much you want to keep on the client side, and
> how much
> would have to be done on the server. For instance, a good
> implementation
> might render the page with the items already generated for a
> particular day.
> Alternatively, you could first render the day planner completely
> empty, then
> do an Ajax call to populate the day once the page is loaded. It
> really
> doesn't matter.
>
>
> Julian Wood wrote:
>>
>> The javascript has many event hooks which fire off AJAX requests
>> to it's
>> PHP backend.
>>
>
> It looks like there's basically just one event (let's call it
> updateEvent),
> fired in a lot of different ways. updateEvent takes a few different
> parameters, but they're all the same no matter what the event
> actually is.
> You could do all this using a single listener, which then parses it
> out and
> stores the information however you like and has a simple return
> code if
> there's an exception thrown, or if there's a date conflict... you
> can make
> it as smart or dumb as you want.
>
>
> I'll also need to put in raw URL's to the AJAX services, directly
> inside the
> javascript.
>
> Have you looked at the XTile component? It's got basically
> everything you
> need. There's really not much *to* Ajax, which is why I find all
> the new
> bells and whistles of 4.1 essentially cruft considering all you're
> doing is
> calling a page listener and maybe receiving return data to the client.
>
>
> So if I can dip into specifics, I know I can get the planner to
> load all the
> "appointments" for a week pretty easily. But how to deal with an
> appointment
> move? A resize (change in duration)? A delete? A double click for
> an edit?
>
> I'd need to understand better how your event objects are
> represented in
> Javascript first and I didn't want to trudge through source code. I'm
> guessing that each event has a unique ID, a start and end time, a
> date and
> some text to go along with it. Something like:
>
> var Events = {
> elements: {},
> eventObj: function(start, end, date, text) {
> this.start = start;
> this.end = end;
> this.date = date;
> this.text = text;
> },
> add: function(id, start, end, date, text) {
> Events.elements[id] = new Event.eventObj(start, end, date,
> text);
> },
> delete: function(id) {
> delete Events.elements[id];
> },
> update: function(id, start, end, date, text) {
> Events.elements[id].start = start;
> Events.elements[id].end = end;
> Events.elements[id].date = date;
> Events.elements[id].text = text;
> }
> }
>
> There's all your event objects on the client side and all your basic
> methods. In your page file add the XTile component from the Contrib
> library. It's dead-simple to configure. You just give it a Send
> function,
> a Receive function, and a page Listener.
>
> For instance, in your HTML...
>
> <span jwcid="@contrib:XTile" sendName="literal:updateEvent"
> receiveName="literal:recvResponse"
> listener="listener:handleRequest" />
>
> The send function is the function you call from the client side
> when you
> want to instantiate the Ajax request. So when you move a calendar
> event and
> the date changes, you'd call the update function and pass all the
> Event
> object elements. Something like,
>
> onWhateverEvent = function() {
> var id = // get the id however you like...
> updateEvent(id, Events.elements[id].start, Events.elements[id].end,
> Events.elements[id].date, Events.elements[id].text);
> }
>
> In your java code, you'll have a listener that then does something
> with this
> info...
>
> public void handleRequest(IRequestCycle cycle) {
> String[] ret = null;
> Object[] params = cycle.getListenerParameters();
> if (params.length < 5)
> return;
> String id = params[0].toString();
> String start = params[1].toString();
> String end = params[2].toString();
> String date = params[3].toString();
> String text = params[4].toString();
> // save the updated object
> // ret == return message
> cycle.setListenerParameters(ret);
> }
>
> Then in your javascript you'll need a function to handle the return
> data...
>
> function recvResponse(xmlstuff) {
> var returnData = xmlstuff.join('');
> // do stuff...
> }
>
> And that's basically it. If you wanted to be clever, you could use
> JSON to
> transport your javascript objects. If you wanted to be very
> clever, you
> could add an additional "action" parameter to your Ajax request to
> make
> coding the listener a bit easier (stuff like "ADD" or "DELETE" or
> "EDIT").
> --
> View this message in context: http://www.nabble.com/Best-strategy--
> tf3201900.html#a8959162
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
-
Julian Wood <wo...@ucalgary.ca>
Software Engineer
Teaching & Learning Centre
University of Calgary
http://tlc.ucalgary.ca
Re: [WARNING] Best strategy?
Posted by Matt Brock <br...@gmail.com>.
That's a very nice little widget there.
This would be very easy to move to the Tapestry world. I guess it would
really depend on how much you want to keep on the client side, and how much
would have to be done on the server. For instance, a good implementation
might render the page with the items already generated for a particular day.
Alternatively, you could first render the day planner completely empty, then
do an Ajax call to populate the day once the page is loaded. It really
doesn't matter.
Julian Wood wrote:
>
> The javascript has many event hooks which fire off AJAX requests to it's
> PHP backend.
>
It looks like there's basically just one event (let's call it updateEvent),
fired in a lot of different ways. updateEvent takes a few different
parameters, but they're all the same no matter what the event actually is.
You could do all this using a single listener, which then parses it out and
stores the information however you like and has a simple return code if
there's an exception thrown, or if there's a date conflict... you can make
it as smart or dumb as you want.
I'll also need to put in raw URL's to the AJAX services, directly inside the
javascript.
Have you looked at the XTile component? It's got basically everything you
need. There's really not much *to* Ajax, which is why I find all the new
bells and whistles of 4.1 essentially cruft considering all you're doing is
calling a page listener and maybe receiving return data to the client.
So if I can dip into specifics, I know I can get the planner to load all the
"appointments" for a week pretty easily. But how to deal with an appointment
move? A resize (change in duration)? A delete? A double click for an edit?
I'd need to understand better how your event objects are represented in
Javascript first and I didn't want to trudge through source code. I'm
guessing that each event has a unique ID, a start and end time, a date and
some text to go along with it. Something like:
var Events = {
elements: {},
eventObj: function(start, end, date, text) {
this.start = start;
this.end = end;
this.date = date;
this.text = text;
},
add: function(id, start, end, date, text) {
Events.elements[id] = new Event.eventObj(start, end, date, text);
},
delete: function(id) {
delete Events.elements[id];
},
update: function(id, start, end, date, text) {
Events.elements[id].start = start;
Events.elements[id].end = end;
Events.elements[id].date = date;
Events.elements[id].text = text;
}
}
There's all your event objects on the client side and all your basic
methods. In your page file add the XTile component from the Contrib
library. It's dead-simple to configure. You just give it a Send function,
a Receive function, and a page Listener.
For instance, in your HTML...
<span jwcid="@contrib:XTile" sendName="literal:updateEvent"
receiveName="literal:recvResponse" listener="listener:handleRequest" />
The send function is the function you call from the client side when you
want to instantiate the Ajax request. So when you move a calendar event and
the date changes, you'd call the update function and pass all the Event
object elements. Something like,
onWhateverEvent = function() {
var id = // get the id however you like...
updateEvent(id, Events.elements[id].start, Events.elements[id].end,
Events.elements[id].date, Events.elements[id].text);
}
In your java code, you'll have a listener that then does something with this
info...
public void handleRequest(IRequestCycle cycle) {
String[] ret = null;
Object[] params = cycle.getListenerParameters();
if (params.length < 5)
return;
String id = params[0].toString();
String start = params[1].toString();
String end = params[2].toString();
String date = params[3].toString();
String text = params[4].toString();
// save the updated object
// ret == return message
cycle.setListenerParameters(ret);
}
Then in your javascript you'll need a function to handle the return data...
function recvResponse(xmlstuff) {
var returnData = xmlstuff.join('');
// do stuff...
}
And that's basically it. If you wanted to be clever, you could use JSON to
transport your javascript objects. If you wanted to be very clever, you
could add an additional "action" parameter to your Ajax request to make
coding the listener a bit easier (stuff like "ADD" or "DELETE" or "EDIT").
--
View this message in context: http://www.nabble.com/Best-strategy--tf3201900.html#a8959162
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Best strategy?
Posted by Pedro Viegas <vi...@gmail.com>.
I there Jesse,
Since we're covering Table componentes and T4.1 is in the comments... is a
Table component in T4.1 roadmap? I seem to recall a previous post from you
stating that it may be so.
If so can you give us any pointer as to what it can become?
We wouldn't want to be building something that within weeks would become
obsolete. :-)
Thanks,
And by the way, are there any plans
On 2/13/07, Jesse Kuhnert <jk...@gmail.com> wrote:
>
> Yeah sorry...Don't let me dissuade you. The "big undertaking" was my
> interpretation of what a more modern looking/functioning version of
> that app might be.
>
> The literal translation of it probably wouldn't be very hard at all
> with tacos or t4.1 (through the use of dojo or any other modern js
> library of course - I'm just a glorified "glue" coder ;) )
>
> On 2/12/07, Holger Stolzenberg <h....@ewerk.com> wrote:
> > In the tacos library the JS Calendar (
> http://www.dhtmlgoodies.com/index.html?page=calendarScripts) in integrated
> as tacos:DatePicker component. May be the tacos sources can help you too.
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Julian Wood [mailto:woodj@ucalgary.ca]
> > Gesendet: Montag, 12. Februar 2007 00:58
> > An: Tapestry users
> > Betreff: Re: Best strategy?
> >
> > Ok thanks Jesse. Even hearing that it _is_ a large undertaking gives me
> some direction. I think I will explore the EventListener annotation a little
> more to see if I can see a way to hook it up to the events created by this
> planner, and if that looks promising I will go down that road. I also hadn't
> realized you could listen for invocations of javascript functions, which
> should give me another route.
> >
> > Thanks,
> >
> > J
> >
> > On 11-Feb-07, at 2:09 PM, Jesse Kuhnert wrote:
> >
> > > I can't make any suggestions for such a large undertaking, but the
> > > @EventListener annotation can listen to any native (browser generated)
> > > javascript event or object function.
> > >
> > > On 2/9/07, Julian Wood <wo...@ucalgary.ca> wrote:
> > >> I'm working on taking this dhtml component here:
> > >>
> > >> http://www.dhtmlgoodies.com/scripts/dhtmlgoodies-week-planner/
> > >> dhtmlgoodies-week-planner.html
> > >>
> > >> and moving it into tapestry. It is heavy on javascript, AJAX and
> > >> somewhat less so on PHP. The javascript has many event hooks which
> > >> fire off AJAX requests to it's PHP backend.
> > >>
> > >> My question is, what is the best strategy for moving to Tapestry?
> > >>
> > >> I think the quickest and dirtiest solution is to create an engine
> > >> service for each of the AJAX calls, which replicate what the PHP does
> > >> in it's current incarnation. This does feel like the wrong way to do
> > >> it though, especially since in each service, I will need to add
> > >> state, while leaving the page's .java virtually empty. I'll also need
> > >> to put in raw URL's to the AJAX services, directly inside the
> > >> javascript.
> > >>
> > >> So, knowing there must be a better way, I've been trying to figure
> > >> out how I can leverage the new stuff in 4.1 to do the job. The
> > >> javascript events in the planner are not straightforward - they are
> > >> calculated, and if necessary, an AJAX call is made. I'm not sure if
> > >> an EventListener can be made to monitor a complex event like that, or
> > >> if you can make a custom event to which an EventListener can listen.
> > >>
> > >> So if I can dip into specifics, I know I can get the planner to load
> > >> all the "appointments" for a week pretty easily. But how to deal with
> > >> an appointment move? A resize (change in duration)? A delete? A
> > >> double click for an edit? Each of these has the additional problem
> > >> that they can be made on the fly, and there can be many of them. How
> > >> much of this can be moved in to a @Script? I'm of course aiming to
> > >> have each of the listener impl methods in my Planner class, backing
> > >> Planner.page and Planner.html, which will have the planner from
> > >> dhtmlgoodies inside.
> > >>
> > >> So does anyone have any suggestions on which road to go down? I know
> > >> my quick and dirty will work, but I'm not sure if this second
> > >> approach will work, nor how much time it will take, but it seems like
> > >> it is closer to "the right way to do it". What is the right way?
> > >>
> > >> Thanks,
> > >>
> > >> J
> > >>
> > >> --
> > >> Julian Wood <wo...@ucalgary.ca>
> > >>
> > >> Software Engineer
> > >> Teaching & Learning Centre
> > >> University of Calgary
> > >>
> > >> http://tlc.ucalgary.ca
> > >>
> > >>
> > >>
> > >
> > >
> > > --
> > > Jesse Kuhnert
> > > Tapestry/Dojo team member/developer
> > >
> > > Open source based consulting work centered around
> > > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
> > --
> > Julian Wood <wo...@ucalgary.ca>
> >
> > Software Engineer
> > Teaching & Learning Centre
> > University of Calgary
> >
> > http://tlc.ucalgary.ca
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
---
Pedro Viegas
Re: Best strategy?
Posted by Jesse Kuhnert <jk...@gmail.com>.
Yeah sorry...Don't let me dissuade you. The "big undertaking" was my
interpretation of what a more modern looking/functioning version of
that app might be.
The literal translation of it probably wouldn't be very hard at all
with tacos or t4.1 (through the use of dojo or any other modern js
library of course - I'm just a glorified "glue" coder ;) )
On 2/12/07, Holger Stolzenberg <h....@ewerk.com> wrote:
> In the tacos library the JS Calendar (http://www.dhtmlgoodies.com/index.html?page=calendarScripts) in integrated as tacos:DatePicker component. May be the tacos sources can help you too.
>
> -----Ursprüngliche Nachricht-----
> Von: Julian Wood [mailto:woodj@ucalgary.ca]
> Gesendet: Montag, 12. Februar 2007 00:58
> An: Tapestry users
> Betreff: Re: Best strategy?
>
> Ok thanks Jesse. Even hearing that it _is_ a large undertaking gives me some direction. I think I will explore the EventListener annotation a little more to see if I can see a way to hook it up to the events created by this planner, and if that looks promising I will go down that road. I also hadn't realized you could listen for invocations of javascript functions, which should give me another route.
>
> Thanks,
>
> J
>
> On 11-Feb-07, at 2:09 PM, Jesse Kuhnert wrote:
>
> > I can't make any suggestions for such a large undertaking, but the
> > @EventListener annotation can listen to any native (browser generated)
> > javascript event or object function.
> >
> > On 2/9/07, Julian Wood <wo...@ucalgary.ca> wrote:
> >> I'm working on taking this dhtml component here:
> >>
> >> http://www.dhtmlgoodies.com/scripts/dhtmlgoodies-week-planner/
> >> dhtmlgoodies-week-planner.html
> >>
> >> and moving it into tapestry. It is heavy on javascript, AJAX and
> >> somewhat less so on PHP. The javascript has many event hooks which
> >> fire off AJAX requests to it's PHP backend.
> >>
> >> My question is, what is the best strategy for moving to Tapestry?
> >>
> >> I think the quickest and dirtiest solution is to create an engine
> >> service for each of the AJAX calls, which replicate what the PHP does
> >> in it's current incarnation. This does feel like the wrong way to do
> >> it though, especially since in each service, I will need to add
> >> state, while leaving the page's .java virtually empty. I'll also need
> >> to put in raw URL's to the AJAX services, directly inside the
> >> javascript.
> >>
> >> So, knowing there must be a better way, I've been trying to figure
> >> out how I can leverage the new stuff in 4.1 to do the job. The
> >> javascript events in the planner are not straightforward - they are
> >> calculated, and if necessary, an AJAX call is made. I'm not sure if
> >> an EventListener can be made to monitor a complex event like that, or
> >> if you can make a custom event to which an EventListener can listen.
> >>
> >> So if I can dip into specifics, I know I can get the planner to load
> >> all the "appointments" for a week pretty easily. But how to deal with
> >> an appointment move? A resize (change in duration)? A delete? A
> >> double click for an edit? Each of these has the additional problem
> >> that they can be made on the fly, and there can be many of them. How
> >> much of this can be moved in to a @Script? I'm of course aiming to
> >> have each of the listener impl methods in my Planner class, backing
> >> Planner.page and Planner.html, which will have the planner from
> >> dhtmlgoodies inside.
> >>
> >> So does anyone have any suggestions on which road to go down? I know
> >> my quick and dirty will work, but I'm not sure if this second
> >> approach will work, nor how much time it will take, but it seems like
> >> it is closer to "the right way to do it". What is the right way?
> >>
> >> Thanks,
> >>
> >> J
> >>
> >> --
> >> Julian Wood <wo...@ucalgary.ca>
> >>
> >> Software Engineer
> >> Teaching & Learning Centre
> >> University of Calgary
> >>
> >> http://tlc.ucalgary.ca
> >>
> >>
> >>
> >
> >
> > --
> > Jesse Kuhnert
> > Tapestry/Dojo team member/developer
> >
> > Open source based consulting work centered around
> > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
> --
> Julian Wood <wo...@ucalgary.ca>
>
> Software Engineer
> Teaching & Learning Centre
> University of Calgary
>
> http://tlc.ucalgary.ca
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Best strategy?
Posted by Jesse Kuhnert <jk...@gmail.com>.
Either way you want to use "FilteringTable" not Sortable. (sortable is
the old version)
On 2/13/07, Julian Wood <wo...@ucalgary.ca> wrote:
> Yes that is a nice table, but I think you could do all that (minus
> the AJAX) with some CSS around the current contrib:table.
>
> Tap 5 has a new grid component you might be interested in:
>
> http://tapestryjava.blogspot.com/2007/02/more-tapestry-5-grid-
> component-case.html#links
>
> I haven't tried the dojo SortableTable, but it seems to me that would
> be a good option, because it should be an AJAX-enabled, model-based
> table.
>
> It seems to me that the dhtml goodies sortable tables would not be so
> good, because they just sort the view, and don't have access to the
> model (I haven't seen one that uses AJAX), so if you're paging, this
> would be confusing for users.
>
> HTH,
>
> J
>
> On 13-Feb-07, at 6:12 PM, Pedro Viegas wrote:
>
> > I there Julian,
> >
> > I'm also about to begin coding a table component of my own.
> > Tell me, have you compared the table from dhtmlgoodies with the
> > SortableTable included in the Tapestry 4.1 provided Dojo?
> > Is there a good reason to this preference? Are there more features
> > in the
> > dhtmlgoodies table?
> >
> > I was very inclined to the dojo table but would like your views on
> > this.
> > What I really would like to have is this...
> > http://www.turboajax.com/turbowidgets/
> >
> > Isn't that grid something? Beatifull... and it's dojo based!
> >
> > Regards,
> >
> >
> > ---
> > Pedro Viegas
>
> --
> Julian Wood <wo...@ucalgary.ca>
>
> Software Engineer
> Teaching & Learning Centre
> University of Calgary
>
> http://tlc.ucalgary.ca
>
>
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Best strategy?
Posted by Pedro Viegas <vi...@gmail.com>.
Damn!
Just reading about that T5 Table gives let's me wishing I could fast forward
time to let Howard finish and release it!
Just seams a waste of time to develop a grid for T4 that is will no even get
close to what Howard describes for a few months life-time...
Oh well...
On 2/14/07, Julian Wood <wo...@ucalgary.ca> wrote:
>
> Yes that is a nice table, but I think you could do all that (minus
> the AJAX) with some CSS around the current contrib:table.
>
> Tap 5 has a new grid component you might be interested in:
>
> http://tapestryjava.blogspot.com/2007/02/more-tapestry-5-grid-
> component-case.html#links
>
> I haven't tried the dojo SortableTable, but it seems to me that would
> be a good option, because it should be an AJAX-enabled, model-based
> table.
>
> It seems to me that the dhtml goodies sortable tables would not be so
> good, because they just sort the view, and don't have access to the
> model (I haven't seen one that uses AJAX), so if you're paging, this
> would be confusing for users.
>
> HTH,
>
> J
>
> On 13-Feb-07, at 6:12 PM, Pedro Viegas wrote:
>
> > I there Julian,
> >
> > I'm also about to begin coding a table component of my own.
> > Tell me, have you compared the table from dhtmlgoodies with the
> > SortableTable included in the Tapestry 4.1 provided Dojo?
> > Is there a good reason to this preference? Are there more features
> > in the
> > dhtmlgoodies table?
> >
> > I was very inclined to the dojo table but would like your views on
> > this.
> > What I really would like to have is this...
> > http://www.turboajax.com/turbowidgets/
> >
> > Isn't that grid something? Beatifull... and it's dojo based!
> >
> > Regards,
> >
> >
> > ---
> > Pedro Viegas
>
> --
> Julian Wood <wo...@ucalgary.ca>
>
> Software Engineer
> Teaching & Learning Centre
> University of Calgary
>
> http://tlc.ucalgary.ca
>
>
>
--
---
Pedro Viegas
Re: Best strategy?
Posted by Julian Wood <wo...@ucalgary.ca>.
Yes that is a nice table, but I think you could do all that (minus
the AJAX) with some CSS around the current contrib:table.
Tap 5 has a new grid component you might be interested in:
http://tapestryjava.blogspot.com/2007/02/more-tapestry-5-grid-
component-case.html#links
I haven't tried the dojo SortableTable, but it seems to me that would
be a good option, because it should be an AJAX-enabled, model-based
table.
It seems to me that the dhtml goodies sortable tables would not be so
good, because they just sort the view, and don't have access to the
model (I haven't seen one that uses AJAX), so if you're paging, this
would be confusing for users.
HTH,
J
On 13-Feb-07, at 6:12 PM, Pedro Viegas wrote:
> I there Julian,
>
> I'm also about to begin coding a table component of my own.
> Tell me, have you compared the table from dhtmlgoodies with the
> SortableTable included in the Tapestry 4.1 provided Dojo?
> Is there a good reason to this preference? Are there more features
> in the
> dhtmlgoodies table?
>
> I was very inclined to the dojo table but would like your views on
> this.
> What I really would like to have is this...
> http://www.turboajax.com/turbowidgets/
>
> Isn't that grid something? Beatifull... and it's dojo based!
>
> Regards,
>
>
> ---
> Pedro Viegas
--
Julian Wood <wo...@ucalgary.ca>
Software Engineer
Teaching & Learning Centre
University of Calgary
http://tlc.ucalgary.ca
Re: Best strategy?
Posted by Pedro Viegas <vi...@gmail.com>.
I there Julian,
I'm also about to begin coding a table component of my own.
Tell me, have you compared the table from dhtmlgoodies with the
SortableTable included in the Tapestry 4.1 provided Dojo?
Is there a good reason to this preference? Are there more features in the
dhtmlgoodies table?
I was very inclined to the dojo table but would like your views on this.
What I really would like to have is this...
http://www.turboajax.com/turbowidgets/
Isn't that grid something? Beatifull... and it's dojo based!
Regards,
On 2/11/07, Julian Wood <wo...@ucalgary.ca> wrote:
>
> Ok thanks Jesse. Even hearing that it _is_ a large undertaking gives
> me some direction. I think I will explore the EventListener
> annotation a little more to see if I can see a way to hook it up to
> the events created by this planner, and if that looks promising I
> will go down that road. I also hadn't realized you could listen for
> invocations of javascript functions, which should give me another route.
>
> Thanks,
>
> J
>
> On 11-Feb-07, at 2:09 PM, Jesse Kuhnert wrote:
>
> > I can't make any suggestions for such a large undertaking, but the
> > @EventListener annotation can listen to any native (browser generated)
> > javascript event or object function.
> >
> > On 2/9/07, Julian Wood <wo...@ucalgary.ca> wrote:
> >> I'm working on taking this dhtml component here:
> >>
> >> http://www.dhtmlgoodies.com/scripts/dhtmlgoodies-week-planner/
> >> dhtmlgoodies-week-planner.html
> >>
> >> and moving it into tapestry. It is heavy on javascript, AJAX and
> >> somewhat less so on PHP. The javascript has many event hooks which
> >> fire off AJAX requests to it's PHP backend.
> >>
> >> My question is, what is the best strategy for moving to Tapestry?
> >>
> >> I think the quickest and dirtiest solution is to create an engine
> >> service for each of the AJAX calls, which replicate what the PHP does
> >> in it's current incarnation. This does feel like the wrong way to do
> >> it though, especially since in each service, I will need to add
> >> state, while leaving the page's .java virtually empty. I'll also need
> >> to put in raw URL's to the AJAX services, directly inside the
> >> javascript.
> >>
> >> So, knowing there must be a better way, I've been trying to figure
> >> out how I can leverage the new stuff in 4.1 to do the job. The
> >> javascript events in the planner are not straightforward - they are
> >> calculated, and if necessary, an AJAX call is made. I'm not sure if
> >> an EventListener can be made to monitor a complex event like that, or
> >> if you can make a custom event to which an EventListener can listen.
> >>
> >> So if I can dip into specifics, I know I can get the planner to load
> >> all the "appointments" for a week pretty easily. But how to deal with
> >> an appointment move? A resize (change in duration)? A delete? A
> >> double click for an edit? Each of these has the additional problem
> >> that they can be made on the fly, and there can be many of them. How
> >> much of this can be moved in to a @Script? I'm of course aiming to
> >> have each of the listener impl methods in my Planner class, backing
> >> Planner.page and Planner.html, which will have the planner from
> >> dhtmlgoodies inside.
> >>
> >> So does anyone have any suggestions on which road to go down? I know
> >> my quick and dirty will work, but I'm not sure if this second
> >> approach will work, nor how much time it will take, but it seems like
> >> it is closer to "the right way to do it". What is the right way?
> >>
> >> Thanks,
> >>
> >> J
> >>
> >> --
> >> Julian Wood <wo...@ucalgary.ca>
> >>
> >> Software Engineer
> >> Teaching & Learning Centre
> >> University of Calgary
> >>
> >> http://tlc.ucalgary.ca
> >>
> >>
> >>
> >
> >
> > --
> > Jesse Kuhnert
> > Tapestry/Dojo team member/developer
> >
> > Open source based consulting work centered around
> > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
> --
> Julian Wood <wo...@ucalgary.ca>
>
> Software Engineer
> Teaching & Learning Centre
> University of Calgary
>
> http://tlc.ucalgary.ca
>
>
>
--
---
Pedro Viegas
AW: Best strategy?
Posted by Holger Stolzenberg <h....@ewerk.com>.
In the tacos library the JS Calendar (http://www.dhtmlgoodies.com/index.html?page=calendarScripts) in integrated as tacos:DatePicker component. May be the tacos sources can help you too.
-----Ursprüngliche Nachricht-----
Von: Julian Wood [mailto:woodj@ucalgary.ca]
Gesendet: Montag, 12. Februar 2007 00:58
An: Tapestry users
Betreff: Re: Best strategy?
Ok thanks Jesse. Even hearing that it _is_ a large undertaking gives me some direction. I think I will explore the EventListener annotation a little more to see if I can see a way to hook it up to the events created by this planner, and if that looks promising I will go down that road. I also hadn't realized you could listen for invocations of javascript functions, which should give me another route.
Thanks,
J
On 11-Feb-07, at 2:09 PM, Jesse Kuhnert wrote:
> I can't make any suggestions for such a large undertaking, but the
> @EventListener annotation can listen to any native (browser generated)
> javascript event or object function.
>
> On 2/9/07, Julian Wood <wo...@ucalgary.ca> wrote:
>> I'm working on taking this dhtml component here:
>>
>> http://www.dhtmlgoodies.com/scripts/dhtmlgoodies-week-planner/
>> dhtmlgoodies-week-planner.html
>>
>> and moving it into tapestry. It is heavy on javascript, AJAX and
>> somewhat less so on PHP. The javascript has many event hooks which
>> fire off AJAX requests to it's PHP backend.
>>
>> My question is, what is the best strategy for moving to Tapestry?
>>
>> I think the quickest and dirtiest solution is to create an engine
>> service for each of the AJAX calls, which replicate what the PHP does
>> in it's current incarnation. This does feel like the wrong way to do
>> it though, especially since in each service, I will need to add
>> state, while leaving the page's .java virtually empty. I'll also need
>> to put in raw URL's to the AJAX services, directly inside the
>> javascript.
>>
>> So, knowing there must be a better way, I've been trying to figure
>> out how I can leverage the new stuff in 4.1 to do the job. The
>> javascript events in the planner are not straightforward - they are
>> calculated, and if necessary, an AJAX call is made. I'm not sure if
>> an EventListener can be made to monitor a complex event like that, or
>> if you can make a custom event to which an EventListener can listen.
>>
>> So if I can dip into specifics, I know I can get the planner to load
>> all the "appointments" for a week pretty easily. But how to deal with
>> an appointment move? A resize (change in duration)? A delete? A
>> double click for an edit? Each of these has the additional problem
>> that they can be made on the fly, and there can be many of them. How
>> much of this can be moved in to a @Script? I'm of course aiming to
>> have each of the listener impl methods in my Planner class, backing
>> Planner.page and Planner.html, which will have the planner from
>> dhtmlgoodies inside.
>>
>> So does anyone have any suggestions on which road to go down? I know
>> my quick and dirty will work, but I'm not sure if this second
>> approach will work, nor how much time it will take, but it seems like
>> it is closer to "the right way to do it". What is the right way?
>>
>> Thanks,
>>
>> J
>>
>> --
>> Julian Wood <wo...@ucalgary.ca>
>>
>> Software Engineer
>> Teaching & Learning Centre
>> University of Calgary
>>
>> http://tlc.ucalgary.ca
>>
>>
>>
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Julian Wood <wo...@ucalgary.ca>
Software Engineer
Teaching & Learning Centre
University of Calgary
http://tlc.ucalgary.ca
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Best strategy?
Posted by Julian Wood <wo...@ucalgary.ca>.
Ok thanks Jesse. Even hearing that it _is_ a large undertaking gives
me some direction. I think I will explore the EventListener
annotation a little more to see if I can see a way to hook it up to
the events created by this planner, and if that looks promising I
will go down that road. I also hadn't realized you could listen for
invocations of javascript functions, which should give me another route.
Thanks,
J
On 11-Feb-07, at 2:09 PM, Jesse Kuhnert wrote:
> I can't make any suggestions for such a large undertaking, but the
> @EventListener annotation can listen to any native (browser generated)
> javascript event or object function.
>
> On 2/9/07, Julian Wood <wo...@ucalgary.ca> wrote:
>> I'm working on taking this dhtml component here:
>>
>> http://www.dhtmlgoodies.com/scripts/dhtmlgoodies-week-planner/
>> dhtmlgoodies-week-planner.html
>>
>> and moving it into tapestry. It is heavy on javascript, AJAX and
>> somewhat less so on PHP. The javascript has many event hooks which
>> fire off AJAX requests to it's PHP backend.
>>
>> My question is, what is the best strategy for moving to Tapestry?
>>
>> I think the quickest and dirtiest solution is to create an engine
>> service for each of the AJAX calls, which replicate what the PHP does
>> in it's current incarnation. This does feel like the wrong way to do
>> it though, especially since in each service, I will need to add
>> state, while leaving the page's .java virtually empty. I'll also need
>> to put in raw URL's to the AJAX services, directly inside the
>> javascript.
>>
>> So, knowing there must be a better way, I've been trying to figure
>> out how I can leverage the new stuff in 4.1 to do the job. The
>> javascript events in the planner are not straightforward - they are
>> calculated, and if necessary, an AJAX call is made. I'm not sure if
>> an EventListener can be made to monitor a complex event like that, or
>> if you can make a custom event to which an EventListener can listen.
>>
>> So if I can dip into specifics, I know I can get the planner to load
>> all the "appointments" for a week pretty easily. But how to deal with
>> an appointment move? A resize (change in duration)? A delete? A
>> double click for an edit? Each of these has the additional problem
>> that they can be made on the fly, and there can be many of them. How
>> much of this can be moved in to a @Script? I'm of course aiming to
>> have each of the listener impl methods in my Planner class, backing
>> Planner.page and Planner.html, which will have the planner from
>> dhtmlgoodies inside.
>>
>> So does anyone have any suggestions on which road to go down? I know
>> my quick and dirty will work, but I'm not sure if this second
>> approach will work, nor how much time it will take, but it seems like
>> it is closer to "the right way to do it". What is the right way?
>>
>> Thanks,
>>
>> J
>>
>> --
>> Julian Wood <wo...@ucalgary.ca>
>>
>> Software Engineer
>> Teaching & Learning Centre
>> University of Calgary
>>
>> http://tlc.ucalgary.ca
>>
>>
>>
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Julian Wood <wo...@ucalgary.ca>
Software Engineer
Teaching & Learning Centre
University of Calgary
http://tlc.ucalgary.ca
Re: Best strategy?
Posted by Jesse Kuhnert <jk...@gmail.com>.
I can't make any suggestions for such a large undertaking, but the
@EventListener annotation can listen to any native (browser generated)
javascript event or object function.
On 2/9/07, Julian Wood <wo...@ucalgary.ca> wrote:
> I'm working on taking this dhtml component here:
>
> http://www.dhtmlgoodies.com/scripts/dhtmlgoodies-week-planner/
> dhtmlgoodies-week-planner.html
>
> and moving it into tapestry. It is heavy on javascript, AJAX and
> somewhat less so on PHP. The javascript has many event hooks which
> fire off AJAX requests to it's PHP backend.
>
> My question is, what is the best strategy for moving to Tapestry?
>
> I think the quickest and dirtiest solution is to create an engine
> service for each of the AJAX calls, which replicate what the PHP does
> in it's current incarnation. This does feel like the wrong way to do
> it though, especially since in each service, I will need to add
> state, while leaving the page's .java virtually empty. I'll also need
> to put in raw URL's to the AJAX services, directly inside the
> javascript.
>
> So, knowing there must be a better way, I've been trying to figure
> out how I can leverage the new stuff in 4.1 to do the job. The
> javascript events in the planner are not straightforward - they are
> calculated, and if necessary, an AJAX call is made. I'm not sure if
> an EventListener can be made to monitor a complex event like that, or
> if you can make a custom event to which an EventListener can listen.
>
> So if I can dip into specifics, I know I can get the planner to load
> all the "appointments" for a week pretty easily. But how to deal with
> an appointment move? A resize (change in duration)? A delete? A
> double click for an edit? Each of these has the additional problem
> that they can be made on the fly, and there can be many of them. How
> much of this can be moved in to a @Script? I'm of course aiming to
> have each of the listener impl methods in my Planner class, backing
> Planner.page and Planner.html, which will have the planner from
> dhtmlgoodies inside.
>
> So does anyone have any suggestions on which road to go down? I know
> my quick and dirty will work, but I'm not sure if this second
> approach will work, nor how much time it will take, but it seems like
> it is closer to "the right way to do it". What is the right way?
>
> Thanks,
>
> J
>
> --
> Julian Wood <wo...@ucalgary.ca>
>
> Software Engineer
> Teaching & Learning Centre
> University of Calgary
>
> http://tlc.ucalgary.ca
>
>
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org