[pLog-svn] Announcing SoylentX.com powered by a souped up Plog

[Jason King]

>Do you have any test user so that we can see the inside? :) I wouldn't
>like to create a test user just for the sake of it...
>
>  
>
Sure,
user: johndoe
pass: soylentx

>I remember you sent me some code regarding db sessions a while ago. I
>am still planning to merge that into the main trunk but I haven't had
>a chance yet, basically because it still needed some polishing (I was
>planning to implement different session backends instead of dropping
>everything into the same class) Did you ever clean this feature up or
>should I start working on my own?
>
>Also, what's the kludge about?
>
>  
>
I had some trouble accessing my database configuration from within the 
class. I don't know why and I have yet to fix it. One thing I did do was 
write the db access code using basic php functions without any 
abstraction layer this seemed to speed up the session by about half a 
second per session hit.

>>I need to put some polish on my extended user profile
>>plugin and re-release that. There's lots of little things here and there
>>that might be good for the dev version. I had trouble when I installed
>>one of the patches that would keep people from overlapping blog names.
>>It had to do with tacking a number,userid, onto the mangled blog name,
>>for some reason that didn't work for me so instead I just validated the
>>name when it was entered and disallowed duplicate names. I think it
>>would be nice if there were two names associated with blogs, one would
>>serve to identify which blog to serve: the subdomain part, and one would
>>actually show up in templates and such: more like a title. That way you
>>could have short catchy urls but have them expand to longer names in the
>>templates. I didn't implement this feature but its definitely a core
>>hack. I changed the way the login works. Now if you login the dashboard
>>is integrated with the rest of the "menu" its the default page instead
>>of "write and article" also I use a little js driven drop down in the
>>upper right corner to switch between blogs. 
>>    
>>
>
>The js menu is something we could add to the main plog, as an addition
>for quickly switching from blog blog instead of clicking through the
>dashboard for those who are concerned about mouse clicks. I'd like to
>see how you implemented it, though.
>
>What I don't understand is which blog you show when logging in. The
>first one to which the user belongs?
>
>  
>
yes. this seems to work really well.

>>I think this alone makes it
>>a whole lot less confusing for your average user. I like it better too
>>because there are less 'clicks' involved. But actually the logged in
>>state, dashboard and navigation and everything is something that I still
>>want to work on. I think what I have is better than the default setup
>>for myself and my site's members. I don't know if it would be for
>>anybody else or not.
>>    
>>
>
>As I said, I'd like to see how it feels :)
>
>  
>
>
>  
>
>>THE BIGGEST PROBLEM with customizing Plog is one that every OS project
>>faces. I as the user/developer want to hack the core so I can make Plog
>>do exactly what I want it to. BUT I also want to take advantage of
>>developments and new versions. How do I do this? (That's rhetorical, but
>>if you have any really good suggestions....) I can use SVN and
>>diff/merge but I'm not an old hand at this and its very tedious work
>>merging code like that. I would love to see a discussion or even
>>documentation of the best ways to go about this. 
>>    
>>
>
>Technically speaking, you should be able to make your changes on top
>of a working tree periodically updated from svn. The svn client will
>take of merging all new changes with your own local changes... the
>only difficult situation being conflicting updates, which may possibly
>happen. I think there was a discussion in the forums not long about
>this, was it with you perhaps?
>
>  
>
Yup. That was me. I still haven't got this working as well as I'd like 
too. Guess I'm lazy.

>>One thing that struck
>>me after I had completed 99% of the work was I wish I was able to create
>>classes that extended core classes rather than hack the core classes. So
>>let's say I want to change a couple queries in the 'users.class.php' DAO
>>I could create 'users.class.ext.php' and just override or add methods to
>>this file instead. That way when I want to upgrade the core I can pretty
>>much just overwrite all my old core files. None of my changes will get
>>touched and as long as all the interfaces stay the same everything ought
>>to work. Its probably not that simple, but at least I would have all my
>>custom changes sitting alone in separate files instead of being wrapped
>>all up in the core code. This would also make it easier to diff the old
>>core version, which is no longer hacked up with mods, with the new
>>version since I could really just see what changed in the core and not
>>have to worry about every line. This would make customization so much
>>easier and less of a headache for developers. I'm not certain how one
>>would accomplish this dynamic loading of classes but it would be cool.
>>(After rereading this paragraph... YEAH! Think about this. Would be a
>>killer technique for OS projects, also maybe call the files .mod or .hack)
>>    
>>
>
>I've been thinking about this since I read your email yesterday and I
>see no easy solution... Let's say that you want to extend the
>functionality of the "Users" class to add a couple of methods of your
>own. One possibility would be to extend the Users class, call it
>UsersExt but difficulties come because of this:
>
>  
>
Yeah, its not necessarily that easy to implement. If done well this 
could be terrific. If not it could be pretty bad.Certainly not something 
to rush into.

>$users = new Users();
>
>we're creating an instance of Users and not of UsersExt so unless we
>replace "Users" with "UserExt" this everywhere, this won't work.
>
>A second option would be to rename plog's core Users class to
>UsersCore and save your own class as Users, which would extend
>UsersCore. Since the name of the class hasn't changed, this would
>ensure that no extra changes are needed elsewhere. When upgrading to
>newer versions of plog, you'd only need to remember which classes you
>renamed and which classes are your own. Something related to this
>would be to ship plog with UsersCore implementing the code and Users
>as a simple class extending UsersCore but providing no code so that
>users could easily add there their own custom stuff.
>
>Yet another option would be to have all DAO classes behave like
>'proxy' classes (or was it the 'facade' pattern?) in which they're
>just a simple "pretty face" for another class that actually does the
>real work. This is the approach that was taken to implement the
>generic user data integration in 1.1, look at how the Users class
>looks like now:
>http://www.plogworld.net/svn/plog/plog/trunk/class/dao/users.class.php
>It's just a bit of common code and everything else are calls to
>$this->_provider->whateverMethod() It adds an extra level of
>indirection, but it also allows to easily to swap between these
>'worker' classes without affecting the interface of the main DAO class
>such as Blogs, Articles, etc. Via some very simple configuration
>file(s), we could specify which 'worker' class is used by which DAO
>class without affecting any part of the code.
>
>The only problem I can see is that you're limited by the interface of
>the main DAO class. Let's say that if Users::authenticateUser() takes
>2 parameters and you'd like it to take 3 because you need some custom
>stuff, you will still need to modify the interface in Users() and then
>the implementaiton of your custom worker class...
>
>A fourth option (I told you I had been thinking about it, remember?
>:)) could be to replace this
>
>$users = new Users();
>
>with this:
>
>$users = new_Users();
>
>or even something like this:
>
>$users = DAO::getUsersDAO();
>
>These two new functions would check somewhere (config file,
>plog_config db table) which class is responsible for dealing with
>users. It is very similar to the third approach but without the extra
>level of indirection (and it needs a few more changes here antd there)
>
>Opinions?
>
>  
>
I need to read up on facade but I think that is the way to go since its 
a well-defined and understood pattern.



>Oscar
>_______________________________________________
>pLog-svn mailing list
>pLog-svn at devel.plogworld.net
>http://devel.plogworld.net/mailman/listinfo/plog-svn
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.plogworld.net/pipermail/plog-svn/attachments/20050627/4a79b058/attachment.html