As promised, here are some screen shots of the progress I'm making on the ted WebUI. Please note, this is very rough at the moment as I'm focusing mostly on functionality, not presentation.

Main View
http://bugsquat.net/main.png

Right now it is showing static data (not from the data files). As you can see it takes on the form of the actual swing application.

Menu Bar
http://bugsquat.net/menus.png

The menus are the same as in the Sing app. Currently most do nothing, but all are being enabled and disabled correctly based on the current selection (as well as the buttons in the center of the window).

Add Show Dialog
http://bugsquat.net/add_show.png

All of the shows in the add show list are retrieved from the server (as teh Swing app does). So far this is the only real data.

Again, it is currently really rough. I just thought I'd let you all know that it really is in progress. Hopefully I can get it integrated into the code stream soon enough, so you can play with it as it is being created.

Cheers.

I call photoshopped

j/k. Looks good mstead. I can't wait to see some UI refactors when you put them in.

That looks pretty awesome

Cool!

Although I have one question about your post about POJO classes. Are you using the same classes at the webUI side or are you rebuilding them there?

I would imagine that ted somehow has an API that streams its data (shows/episodes, etc) into XML, the webUI picks that xml up and converts it back into his own counterparts (so TedSerie becomes xml becomes a WebTedSerie or so?) or do you use the same .java files at the webui side?

I'm asking, because if the API has to stream ted's classes into xml, they don't have to be POJO, you can simply only stream what you want to bring over to the WebUI side, leaving out all the other stuff.

I was hoping that I could re-use the same objects on the Web side as on the server side. I do not want to have to create a mirroring object just to pass data to the client.

The WebUI will ask for the same data that the current Swing UI does. For example, in the simplest case, take the "Add Show Dialog". User clicks the "Add Show" button, or menu item, on the MainView of the WebUI. Currently, GWT makes an RPC call to the server via na RPC service (AddShowsMessageService) which in turn calls TedIO.getShows() (not sure if this is the actual method name ), and returns a list of SimpleTedSerie objects to the client to be rendered in the show list of the dialog.

This worked out great b/c SimpleTedSerie was a simple pojo. No fancy date conversions, ect... I don't want to have to call TedIO.getShows(), then convert the list of what it returns into a very similar object just so I can get it back to the server. This would be inefficient.

GWT handles the streaming b/w client and server over RPC. So I was hoping that when the client made a request to the server, all I would ever have to do is to have the server retrieve the data that the client was requesting reusing the code that has already been written to do this. I don't want to have to recreate a web version of our domain model. They are relatively big classes, and will likely look identical.

I can see using something like WebTedSerie if we were not writing a FULL web UI for ted, but some web window into some data of ted, where you only need a subset of the properties in the TedSerie class. Why transfer piles of data that will never be used.

Hope this makes some sense (its early in the morning)

Comments?

Hi !
I have talked about this feature in forums and uservoice a couple of times and as such have professional super-user know-it-all opinions

I try to follow your reasoning for the design choices you are making and: Am i right to understand that the reasoning behind GWT is that u can re-use the classes from the fat-client GUI in the web-GUI? If so, i understand why this would be very time-reducing.

I just wanted to point out a couple of things for my own, very personal, use-case for TED.
1. I use rTorrent on a headless linux server (ubuntu) setup with a lot of scripting to automate torrent-downloading and file-management. My goal is not to have any manual intervention at all when i am done except cleaning up every year or so. I have scripts that move completed torrents, unpacks them and creates symlinks in virtual directories for human reading of content in the directories. (for tvshows this is something like tvshow/season/episode.avi) I use Plex as a media-center on osx as a client to watch the content
2. I like TED because it is wife friendly in adding tvshows and it really has some very nice features compared to the exisiting Python-scripts (such as pytvshows or rssdler.py, both at google-code)

Enough about that... rTorrent is a nCurses based client to libtorrent. Rtorrent exposes all available commands to managing and manipulating torrents via XMLRPC in an "open" format. The consequence of this is that there currently exists more than 10 different front-ends to rtorrent. Both web-,GUI and script-frontends. Each with its unique features and look/feel. (I use ruTorrent, also on google code). My point here is that a non-proprietary interface that relies on simple mechanisms like XML for communicating with the server side of the code will most likely open up the development of front-ends since the knowledge necessary to build the front-end is limited to that specific "language", such as PHP, and how that solution then integrates with the XMLRPC layer (or whatever library that is used). I understand that this means you will have to develop a completely new GUI based on TED and that the re-use of classes/code is limited.

Since i am not a coder (anymore) i don't know how much work it would be to do a "2-in-1" solution, where you keep the current design decisions for GWT and also implement a generic interface to control/manipulate TED (such as XMLRPC)? Am i rambling or does this actually make any sense to you guys ? This would also de-couple all transactions to the server (do not assume that a transaction can be written at will) - which can be the case if client and server are on different machines.

Maybe just stirring up dust and if so please dis-regard this post.

And btw. Keep up the excellent work !

Rgds,
beetle

Thank you for the excellent suggestions beetlezap.

I agree, a generic interface would be handy to add.

I think that the current work in adding a gwt interface is going to solve a pile of dependencies between the core code, and the swing interface. The adding of this second interface should point out the places where code has to be pulled apart.

Once that is completely, I believe it should be much easier to add a generic interface. Be it protobufs, xmlrpc, or whatever. The main work needed for any of them in a solid interface on the core code.

I am working on separating out the domain model into a set of smaller, independent classes. My plan is to persist them using JAXB, which basically means they become XML. Once this is competely passing them between client and server should be much easier.

So, I think to answer your suggestions. We're headed in that direction and keeping other interfaces in mind, but it might take a bit to reach the destination .

Oh, and thank you greatly for the use case, it helps to know how people would like to use ted.

Great info. Thanks for the reply. I would love to help out testing and can run ted on OSX 10.6.1 and Ubuntu 9.10
Happy halloween

Hey Beetlezap! Thanks for the feedback/suggestions.



Unfortunatly GWT does not allow us to reuse the code from the fat-client. I wish!!!

I chose GWT for a couple of reasons:
1) GWT code looks VERY similar to Swing and would be easily picked up by other developers of Ted.
2) The ajax/rpc support is right out of the box.

It allows us to focus on the key item we need to get out of the way. i.e. Separate the CORE of TED from the UI. Although the web UI will be basically rebuilding the Swing UI, it will help identify the API that can be used by almost any language to communicate with TED. Unfortunately, this is still quite a ways away.

I think KenMacD sums it up nicely. And thanks for the post!

Cheers.
Mike

I've been pretty busy last week, so I haven't had much time to work on the web UI. Just thought I'd give you all an update on where I am and what I'm up to.

I've been working on separating the web ui and ted into separate maven modules, and to introduce a separate eclipse project for the web UI.

The reason for doing this is that it allows Ted developers to continue to work on core Ted without having to mess around with installing GWT and the Google Eclipse Plugin.

In order to support this, I had to move Ted's source code down a level (as a child project) to support maven. So the directory structure looks like this (names may change):

Ted
-- ted-core
-- everything here is identical to what is currently under trunk
-- ted-web
-- everything here is related to the GWT project.

Running from the ted-core directory will build the ted.jar as it does today.

Running from the ted-web directory will build the ted.war for the web UI.

Integration of the web UI into Ted will come once the domain objects are cleaned up.

I haven't done any more work on the web UI side of things b/c I wanted to get this build stuff out of the way first so I can finally get the web project committed and off my local machine.

NOTE that the only changes that will affect developers when I get around to comitting this stuff is the directory change (pushed down one level). You may get some merge conflicts b/c files have moved.

If there are no objections, I'll aim to get this change comitted tonight or tomorrow evening.

Again... Kenny thanks for the review of the Maven stuff.

The above mentioned maven work is comitted.

Make sure you re-import your eclipse projects.

Awesome, thanks Mike, now we can get down to defining a nice jaxb domain.

NP kenny.

I had to remove some empty directories this AM. GIT-SVN apparently didn't know to remove them.

Anyway... Yeah... A nice simple solid JAXB domain would be great! I'd love to see that XML parsing code disappear.

One thing on my mind that I have to look into... Do you know if JAXB marks it's Java objects up with any other interfaces/base classes? If so, this might be a problem with GWT. One thing we have to remember is that GWT can only use a subset of Java classes on the client. Therefore, domain objects need to be simple Pojos.

I'll double check, but I don't believe it does. Just a simple set of annotations.