Re: [Eclass-devel] my future involvment in eclass

[Kevin O. <ke...@tu...>]

Hi Stefano,

On Nov 12, 2003, at 3:29 PM, Stefano Gaburri wrote:

> Hi everybody (there must be at least another one!), I'm using the list 
> this time instead of the personal mail in case somebody else pops 
> out... it may always be, right? Ok, just joking - "Hello, Kevin"  :)
>
> I talked to the university today and I've got bad news: their project 
> has been delayed until (at least) september 2004. They hope (against 
> hope) to find some more money to make something significant instead of 
> a sad, useless demo (hey but I'm good developing _those_ ... agh).
>
> Seriously, there's also a very good piece of news: another client (the 
> ministry of culture, you'd say "department" in the US I guess) is very 
> interested in making some electronic courses available; these would be 
> web-based and not on CD. So, it looks like I'm going to have the time 
> to really delve in the system. Right now I'm going to work on three 
> main areas (besides trying to figure out how the system works, of 
> course):

Great! I hope this pans out for you (and also for EClass)! =)

> 1) modelling. I need a more refined/powerful course model than a 
> simple string of eClass pages. Of course I don't know anything (yet) 
> about the IMS specification and I don't know how easy it'll be to 
> "drop" new types in eClass according to a hierarchical type 
> organization. I suppose it'll be very easy if not trivial. I know 
> there are templates, but do they allow the encapsulation of old types 
> (templates) within them? I bet they do!

Basically, the IMS Specification is about structure/organization and 
metadata. Every item in the IMS XML file is basically a pointer to a 
file (i.e. "myfile.html") with metadata specified, as well as 
information on where in the hierarchy the page belongs. It doesn't 
store anything regarding the data itself, in that sense you can think 
of it as "content management" data. So as long as you create a file 
type (be it HTML, XML+CSS, etc.) to hold your data, the IMS 
Specification will accept it. So create a new "type" can even be done 
without EClass knowing anything about what that type is. You just tell 
EClass what the file extension for your "type" is and what folder files 
of that type can be found in, and EClass will pass on the files to your 
plugin for editing. BTW, related to this, I just created an "Import 
File..." function in EClass so that you can input any file (PDF 
included) as a page in your EClass!

As for sub/superclassing of types, fortunately Python does make this 
very easy. I haven't yet created a "BasePlugin", simply because I've 
been defining the format over the last year or so and wanted to create 
a few plugins to know what should be in the BasePlugin. I've started on 
some docs (which I hope to have by the end of this week, or early next 
at latest) and reviewing my code I thought I have enough of an idea of 
what each plugin needs to put some encapsulation in there. =)

> 2) this is both for building and deploying: Zope integration. The 
> final product has to support at least user login/authentication and 
> the saving of the user's state. Something like: last page visited, 
> "lessons" taken, quizzes done etc. It will also have to support 
> different access to different parts of the course, e.g. "you can take 
> this quiz only two times" versus "you can re-read the old lessons as 
> many times as you want". Something like that.
> It seems to me, at this point, that porting everything to Zope would 
> be the Right Way (tm): of course such a course would need Zope support 
> at the provider, a minor annoyance, but I know there are many ways to 
> "dump" a Zope site to static HTML (using wget or a python script), so 
> this would be a solution for those who want to generate simple HTML. 
> Not to mention, Zope can be burned and auto-run from CD as well.
> Of course this would dispose of the current eClass-builder, but only 
> really with its current interface: the structure would be ported in 
> Zope and its main functionality would be as well. Kevin could not like 
> it, though, given the effort he put in it, and considering that I 
> still have to demonstrate that Zope would be a friendlier editing 
> environment (although i believe it would).

I don't think we need to "choose" an interface, we simply can support 
both and let the user choose. Heck, they can even use both if they 
want. (EClass at their desk, Zope on the road =) In fact, 
theoretically, one could use any system that supported the IMS Content 
Packaging Specification to edit EClass data, although realistically if 
you create specialized data types their system doesn't understand, it 
wouldn't completely work.

The plugin architecture expects a class called EditorDialog to edit the 
interface; we can simply add an option for a ZopeEditor interface which 
is used when the user is working in Zope. The rest of the code (data 
structures, HTML publishing) is portable (doesn't require wxPython) 
precisely because I envisioned someone developing a web-based interface 
for EClass. I've wanted one myself. But I also want to be able to do 
advanced HTML editing, theme-previewing and other things as well that 
are more feasible and don't have cross-browser support issues.

Not to mention I want the preview window to work with every embeddable 
browser on every platform. <G> It's actually a very useful feature, I 
know because a week or two after I sent out the first beta with that 
feature, I'm getting questions about why this is different (or doesn't 
work) on Mozilla. Hardly *anyone* bothered to ask before. I actually 
said "Oops!" a couple times when I found Netscape/Mozilla related bugs 
in EClass because of this feature. :-) So I think giving people a 
choice is a Good Thing (tm) here. =)

> 3) this is petty: I need something pretty - much prettier that the 
> current ebuilder output. I know it's not the most important thing, but 
> for my client it will probably be - i.e., I can already picture them 
> seeing the grayish "default" site and going something like "ugh, we 
> spent all our money on this" (of course, the quality of the framework 
> would count nothing....). So, this is another thing I'd like to 
> investigate/develop: a system to "prettify" the final output via 
> CSS/XSL or whatever. I admit, I never really got into this new web 
> technology, it seems it's about time...

This is not petty at all - a good interface is a key component to 
getting people open to learning and keeping them interested! Oh yes, 
and the bosses really like it too. =) Basically, the EClass theme 
system is pretty simple and extensible. The plugins have been 'taught' 
to output plain HTML code + Javascript at this point, but there's no 
reason we couldn't put some div tags into the output to allow 
developers to define CSS styles for the output. Again, I made a 
"HTMLPublisher" class so that one could define other classes 
eventually, such as "PDFPublisher" or "XHTMLPublisher". Getting the 
interface to work right on both IE and Mozilla will be tough, but you 
can create some pretty cool interfaces with XHTML+CSS+Javascript these 
days as long as you test, test and test. Using non-XHTML XML tags for 
the browser output hasn't really caught on in my experience - I haven't 
tried it seriously but I'm pretty sure you'll run into some 
cross-browser problems. The main reason for no pretty themes yet in 
EClass is because themes are new, and I've been focused on getting 
everything working first. Themes are actually only a few months old. =)

Thanks,

Kevin