[Server-devel] Looking at edublog moodle code --

[Tarun Pondicherry]

Hi Martin,

Really sorry for the newb mistakes.  This is my first time on a project 
where the repository is actually significant.  I'll be sure to pay close 
attention to my commits in the future.

The Moodle I used as a base is from: http://korpelainen.net/weekly19.zip 
linked from the forum discussion at: 
http://moodle.org/mod/forum/discuss.php?d=96160
The reason is that the Moodle in the catalyst repo had a 1/2 done 
tinyMCE integration and it was *really* frustrating to figure out what 
functions did what you'd think they did or were just "to be implemented 
type things".  However, after working with it for the summer, I think I 
can probably patch tinyMCE into the catalyst version.
On top of that, I simply copied in the OU Blog module and a theme, but 
those are self contained in their respective directories.

All that needs to be done to get tinyMCE working is to enable tinyMCE 
and copy in the Sugar theme folder and change one line to let in 
moodlelib.php to tell it to send an editor to the XO (not a textarea).  
This will give a demoable version with patchy localization support, 
patchy file upload and will need to fall back to HTMLArea in IE.

Anyway, I believe I should be cleaning up the messes I create, so I'll 
try to write two patches based on the current moodle-r2 code in catalyst 
(1- enable tinyMCE, 2-integrate the Sugar theme).  With some luck I 
should be done by Monday.

With regards to future maintainability of EduBlog, I think I'd like to 
split it up into a "Sugar tinyMCE editor" branch that has changes to 
pertaining how that would work and a "OU Blog Branch" that contains the 
actual changes for ou blog.  Is this the sort of thing branches are 
meant for?

Thanks,
Tarun

Martin Langhoff wrote:
> Hi Tarun,
>
> I'm looking briefly at edublog's moodle code. Was hoping to be able to
> cherry-pick the patches making the html editor changes, but your
> "initial" moodle commit is with the _modified_ moodle already...?
>
> I am looking at ab1232242ab51336e9b0fc9aed1443bc35fe1d49 - but from
> what I can see, that's not a pristine moodle, it's a moodle where
> you've made changes already. Correct? Is there a way to separate
> those? Do did you base your work on a specific version of moodle(which
> I can diff), or did you grab a daily?
>
> What follows is a bit of a style nitpick -- don't take too badly...
> it's just that reusing your code is easier if you follow some
> guidelines...
>
> First - one topic per commit, only. For example:
> - c4a3130ec48cd1fa2eb65fc1e0f59cada1f4b7db "fixes to write upload" is
> a good commit dealing with one area / feature
> - a1170158d7fb5185287a6a8525aa87718c7959b6 is not so good ;-)
>
> once you are doing that, you can put the area as the 'prefix' in the
> first line of your commit. So you write as first lines stuff like...
>
>  xotheme: fixed the frobniz
>  oublog: fix db conection in blogger api client
>  xift: import of pristine xift framework version 0.1.2.3
>  xift: hacked to work on XO
>
> which means that just by scanning the listing in gitk I can spot all
> the commits that are important for a particular thing I am looking
> for...
>
> In terms of basing your work on something existing - like moodle! -
> ideally, you'd be using a branch based on a repo that has all the
> history (like the catalyst-maintained moodle-r2 git repo.  That shows
> all the moodle history, and then you open up your branch, do your
> custom work, and you can also merge in updates (like security fixes)
> from upstream.
>
> That's best practice. Second best is to make an initial import of a
> 'pristine' version, just unpacked from the tarball. Make sure you
> mention the exact version in the commit msg. And then make your
> changes in separate commits. This means that if you want to re-apply
> your changes on a new release of the thing, you have your patches
> clearly separated in git.
>
> Anyway, my fault for not looking into your code earlier. It's been a
> ton of work on other issues. Now we got to find a way to see how that
> initial import commit can be separated into bits I can review and
> reuse...
>
> cheers,
>
>
>
> m
>