[Sugar-devel] [Sugar-GSoC] Print Support (Moodle or No Moodle)

Andrés Ambrois andresambrois at gmail.com
Tue Jul 7 01:36:27 EDT 2009


On Monday 06 July 2009 01:28:00 pm Vamsi Krishna Davuluri wrote:
> Hi,
>
> So I had spent almost 3 weeks entirely with Moodle,
> and I have failed to be half as productive with Moodle
> as I have with sugar.
>
> I would relate the reasons to be:
>
> My lack of an estimation on moodle's vastness,
>
> 1) I had no experience with web oriented systems
> 2) I had no prior experience with php and databases
> 3) The assignment plugin which is a what I'm intending to
> base my print Module is very huge (4000-5000 Lines of code)
> It would take me a while to hack it and tune it down.
> 4) I still haven't hit the comfort spot with moodle
> 5) I can't figure out what does what exactly.

Vamsi,

  Don't Panic! We can help you if you try to ask questions we can answer [0]. 
I really recommend you to read that document whenever you have time, which may 
not be right now...

  If you get stuck, search in Google, if you're still stuck, we're here to 
help you, but try to give us something we can answer. Usually a Good Question 
is a variation of "I'm trying to accomplish X, I've written this code: <code> 
and expect it to do Y, but its doing Z. I've searched Google about this but 
couldn't find more information. Any help would be appreciated"


> As a bear essential, I could get the assignment module to have
> a print option, but I don't exactly have the code ready for it.(its
> back at my home place)

You already got the newmodule test module working the other night. This module 
includes examples of moodle's abstraction for forms, database, and themed html 
output. If you want to see what the hell all those functions are, I suggest 
you run an rgrep (or grep -r) in moodle's root dir for 'function 
<function_name>'. Moodle might be huge and crazy but its pretty well 
commented. 

Dont try to hack the assignment module into your printing script. Just take 
code from it.

Following this module's structure, view.php would contain the teacher UI, 
mod_form is for setting up the module instance the first time (and configuration 
thereafter) and another script would contain your xmlrpc entry point. Writing 
an XML-RPC server in PHP is trivial as you can see in [1]. 

From the assignments module you pretty much only need the file handling stuff. 
This is basically done using file_area($userid) to get a directory where the 
files are stored (see lib.php in the assignments module). 

For the upload, the xmlrpc server code would need to use file_area_name($USER-
>id) to get a dirname, and then write the file to it. 

You will also want to have a table to store information for each file (original 
filename, user, time of upload, status), you can declare this table in your 
module's db/install.xml, en then you can access them with the get_record, 
delete_records, update_records, etc. Grep the code for these function's 
headers. 

For printing I've already pointed you to [2]. 

This is just my vision of the solution. I think you should sit down, go 
through all these steps and see if you can understand the picture enough to 
have an idea of a schedule before moving on. If you don't understand how to 
achieve something please ask me or the list concrete questions to get you back 
on the road. 

This is why I insisted so much on detailed schedules, so we wont have huge 
surprises :). 


> Anyway, the alternatives I can lay out are:
>
> 1)Use a thin client-server based architecture, a small python based server
> script
> which listens to requests from sugar (XOs) and stores them in a folder, the
> admin
> can then print those files.
> ( suggestions on perfecting this are needed)

I don't see how you can build something useful in this direction without 
getting into problems already solved for you in Moodle, such as user 
interface, authentication and database handling (at least in some files). 
Please remember the objective of this project is to produce something that can 
be used in the field by kids and teachers as easy and transparently as 
possible.

> 2) drop this, and focus on network printing.

If with "Network Printing" you're referring to discovery of printers through 
Bonjour/Avahi, I don't think this is a priority for our users. This is also a 
big question mark as "Network Printing" is as far as your specification goes. I 
don't want to add variables to an already late project. 

> Thanks,
> Vamsi

We can hopefully discuss more in tomorrow's meeting.


[0] http://catb.org/esr/faqs/smart-questions.html
[1]http://hell.org.ua/Docs/oreilly/webprog/pcook/ch12_08.htm
[2]http://www.nongnu.org/phpprintipp/
-- 
  -Andrés


More information about the Sugar-devel mailing list