XOOPS 2.30 kick-off and task distribution

  • D.J.

    D.J. - 2008-01-09

    Hi developers, we are now back on 2.30 branch, let's write down the part you are or will be working on so that we won't conflict with each other.

    As far as I know, from people's emails or chats with me, some of the tasks have been taken:

    mboyden - profile module
    phelim - pm module
    dugris - admin area
    nekro - banner functionality refactor
    ppcm - user management crossing modules, persistance objects
    If I made mistake, please correct me.
    I would suggest to create a branch instead of submitting commits to TRUNK directly IN CASE you have very big changes in code.

    Meanwhile we have other developers on other branch, like julio_nc and me will take care of; I will watch 2.30 adding some minor fixes and continue my coding on 3.0

    • Est. Simon Antony Roberts

      That's - uk-therapists.co.uk/ which i could spell..

    • Laurent JEN

      Laurent JEN - 2008-01-09

      I worked on the installer (120976-install) for xoops france

      • Request login and password administrator, if this is not the first installation
      • Adding XOOPS_TRUST_PATH for GIJOE's modules (Especially for Protector)
      • Adding Password strength meter for Administrator Account
      • Adding Password generator for Administrator Account
      • Adding "Site configuration" : Site name, Site name, Allow new user registration, Meta keywords, Meta description, Meta author and Meta Copywrit, by default, but other elements may be added in a configuration file
      • Adding the installation of modules
      • Adding Choice of the theme by default
      • D.J.

        D.J. - 2008-01-09

        One suggestion if it has not been under your consideration:
        make the above options optional, that is, list those as "advanced options" so even if a webmaster is lazy to set those options at install, they can have default values.

    • Mark Boyden

      Mark Boyden - 2008-01-09

      Where will we present, manage, and get feedback for the functional requirements and enhancement requests for these tasks? These forums and the SF bug/enhancement tracker really are pretty poor frameworks for this. Will we do it on the wiki? I'd just like to see one, simple place to capture it all. I'll do a quick write-up on the Profiles module to present wherever this is, and then will solicit feedback from the community for it.

      Also other things discussed have been:
      Updated Blocks Engine
      Updated Forms Engine
      * Updated Editor Framework
      as well as easier module cloning and SEO streamlining, among others.

      However, I know this was generally a merge, so probably only the Editor aspect needs to be updated along with things like the admin area and such (includes blocks, templates, and other functions from the Mexico team, along with GIJoe's contributions via AltSys, right?)

      I just think we need to make sure we capture stuff well and then move XOOPS forward well.

      • XoopsGold

        XoopsGold - 2008-01-09

        I have made many changes in the profile and system modules and works like a charm. This is for an association who required an extended profiles management.

        Here are some enhancements:

        1. XoopsMailer gets an extra Command passed on from anywhere and that may change something within the function.
        2. Find Users is completely overhauled.
        3. A system of generating dropdowns by simply give field values somewhere.
        4. Possibility of making display modus for find users.
        5. Masks of find users looks very different than default, more functions and features.
        6. Results from find users enhanced.
        7. Extended statistics of groups and an overview of groups management with user-stats.
        8. Resetting passwords at the level of Xoops mailer where it is generated, inserted and send without display.
        9. Unsubscribe key management.
        10. Possibility of making ALL CHANGES viewable by the admin by inserting those changes in the profiles in the respective profile medium-text fields.
        11. Construction a Protocoll of all that happens in the account changes and saving it, including of logging, IP, etc.
        12. Possibility of using pre-configured templating system and applying those templates to selected user profiles from find-users of through email to groups functions.

        Uh, I do not even remember all those features that I have developed, which works extremely well. All I know that those scripts do not look like in the distribution.

        Well, if one wants, may rework on my codes and send for consideration to be included in the distribution. Then I will have to clean the code quite a bit.

        What I also plan to do is also make it Ajax sensitive integrating it with Xajax, like I said earlier...

        What interesting would be also to plug the email-templating system with an existing module like Articles, etc. and have the admin work on those templates of that module. Then the system will find out which template needs to be attached while relay of the massmail.

        • Mark Boyden

          Mark Boyden - 2008-01-11

          I would love to get a copy of this, and I would love any assistance on the module. I've posted a discussion thread on the X.o forums as well as a wishlist in the X.oWiki wishlist looking for comments and feedback. This would be great to have. Thanks.

      • D.J.

        D.J. - 2008-01-09

        The task manager is intended for our developers, which is not so friendly to users

        Perhaps we should use a Wiki page on xoops.org wiki?
        what's your thoughts?

        I get used to any tools, either interface friendly or not :)
        However, sourceforge speed is very low, much worse if I go back to China.

    • Garrath

      Garrath - 2008-01-10

      Sorry for my bad english

      I see here this :
      * Updated Blocks Engine

      I see also action on persistance objects etc...

      I think the first state it to refectoring actual xoops core.
      Look xoopsBlock and you see why. There is 2 differents class. The xoopsBlock in kernel folder and an other one in class folder. The class in class folder is not and xoopsObject with XoopsHandler... it's very bad... but you know what, this is this class which are using by admin /system module (and other module like cbb...).
      This is for xoopblock but also for other kernel/core class.
      (refactoring make use of the good class, make less code etc... make good exemple for module's developper)
      - I have begin this work but not completely finish actually for xoopsblock... I don't change the block engine, i try to have the same result but with the good way (en français isofonctionalite)... and after rest the other...

      For persistance object you can use 2.2.5 with just one or two correction, if you use it in a good way, you can have very less code (i do it practicaly for all class in kernel folder (but in php5) , you can have some class with just the constructor with initVar(...)...).

      I have maked a change on xoops_gethandler for have a parameter choice of kernel class in db, then after you can change class easily. I don't have make IHM actually for this but i think it's good way for tests and developpement of class if you want work easily (like a simplify 'Spring' features but in db not in xml).
      After when this feature will be good (IHM for managing, etc...) it'll be good way for change, in example, xoopsUser for adding some column in table etc...

    • D.J.

      D.J. - 2008-01-11
    • Garrath

      Garrath - 2008-01-12

      Sorry for may bad english

      I try to dl all the branch 145431, i can't do it. Then i can't see all the work.

      Now there is a factory with this name it's more easy to understand ;-)

      I think XoopsObjectFactory->loadHandler go in place to xoops_gethandler for future.

      But if i can make an idea, don't make the same code with concatenation with name and prefixe for found class.
      $className = "XoopsObject".ucfirst($name);
      90 if (!class_exists($className)) {
      91 $path = empty($path) ? XOOPS_ROOT_PATH . "/Frameworks/xoopsobject" : $path;
      92 if (! @include "{$path}/xoopsobject{$name}.php") {
      93 return null;
      94 }
      95 }

      With this code you cannot change class by an another if you want.

      And after normaly, if you use correctly XoopsPersistableObjectHandler you can have some xoopsobject with just XoopsPersistableObjectHandler and just XoopsObject construct. With your method here you must have two class XoopsObjectToto and XoopsTotoHandler.
      With XoopsPersistableObjectHandler you can have some kernel class like this just like this :
      class XoopsConfigCategory extends XoopsObject
      * Constructor
      public function construct()
      $this->initVar('confcat_id', XOBJ_DTYPE_INT, null);
      $this->initVar('confcat_name', XOBJ_DTYPE_OTHER, null);
      $this->initVar('confcat_order', XOBJ_DTYPE_INT, 0);

      with no special XoopsPersistableObjectHandler .

    • D.J.

      D.J. - 2008-01-12

      "But if i can make an idea, don't make the same code with concatenation with name and prefixe for found class. "

      Do you mean that we should not add prefix to Classname or file name, use $className = $name directly?
      I think it is question of strictness or flexibility.
      Any opinion?

      As for XoopsPersistableObjectHandler, do you mean that we should modify XoopsObjectHandler instead of adding an extra class of XoopsPersistableObjectHandler?
      I think we need provide an abstract class for developers.
      If we modify XoopsObjectHandler to what XoopsPersistableObjectHandler is like, then we need copy current XoopsObjectHandler to some other class like XoopsAbstractObjectHandler.

      • Garrath

        Garrath - 2008-01-17

        "But if i can make an idea, don't make the same code with concatenation with name and prefixe for found class. "

        Do you mean that we should not add prefix to Classname or file name, use $className = $name directly?
        I think it is question of strictness or flexibility.
        Any opinion?

        I think play with concatenation with name and prefixe is no flexibility and you cannot have some great purpose ;-)

        I'm looking the 145431-XoHandler-sanitizer branch.
        Actually i'm working on xoopsObject etc... I just take XoopsPersistableObjectHandler from 2.2.5, i write it in php5, i put somme optimisation etc... I want to have a complete compatibility with actual way of xoops. Then i work step by step ;-)

        My idea it, first to make all xoops core code use xoops_gethandler etc... for prepare future (is not the case actually)
        and after when all sql query will be in different class from xoopsObject, my idea is to get off sql query from this place to put in db factory are anything else. Because some query may be not the same on different db, and you can have choice to put in flat file, xml file or db etc...

        If i understand the code in the 145431, is it the use of your array handler in xoopsObject?
        If it's this use, why do you have an array of handler ? Why handler for read and for write?

      • D.J.

        D.J. - 2008-01-15

        Garrath, your last post is too long, I moved it to a new thread:

    • XoopsGold

      XoopsGold - 2008-01-13

      Hello Mark!

      "Mark Boyden (mboyden) - 2008-01-11 15:37
      I would love to get a copy of this, and I would love any assistance on the module."

      I did not quite understand your message. Since it was immediately after my message, I thought of adding a comment to it.

      I have worked on many functions and modifications of profiles/system module as well as other areas. They are done, most of them, and functioning on live website of an association. All I need to do is to extend my work and make it general for its use for others, as they are currently reduced to the associations requirements. To make everything faster, I have hardcoded many things like fieldnames and that needs also to be cleaned up and changed.

      Well, I have started working on an independent module on my own.

      http://xoopsgold.sourceforge.net/ >>> coming soon!

      My intention is also to add Xajax, which I have to start from scratch to apply to the module. I have now dropped the idea of integrating jquery due to its nasty behaviour with xajax and even the developers of xajax could not help to solve my problems.

      Further, I would like to incorporate niceforms with its non-jquery version.

    • Garrath

      Garrath - 2008-01-13

      hum... how do i get this branck #145431 because look it in my browser is not fun?

      I have tortoise in my PC, when i try to get the branch, it asks me for a login and password.

    • pemen

      pemen - 2008-01-13

      As you have probably already seen, I'm not very active as core dev for the last months.
      Actually I haven't many time for XOOPS to make a good and complete work in the core team.

      I've seen that the 2.3 is on the way, but I don't think I will have a lot of time to work on the new framework and architecture.
      I propose you to focus only on authentication and I will try to take the time to adapt authentication system (LDAP, AD, OpenID, ...) to the new framework that will be released for 2.3/3.0.
      But perhaps that someone else want to take relay on authentication system!!

      Where is the best place to follow your conversation on the new framework?
      Here I suppose

      • D.J.

        D.J. - 2008-01-15

        Currently let's have our discussions on new framework in this forum.
        I will watch your work in case no other developer having time with you.

    • Laurent JEN

      Laurent JEN - 2008-01-13
    • nekro ( XOOPS )

      nekro ( XOOPS ) - 2008-01-14

      Hi everyone... i want to tell everyone... that i am incharge of the banners module... i will also will be glad to help in any other issue you need.

    • Est. Simon Antony Roberts

      Needs a multiaccess portal functions in and for other domains and subdomains using the same installation. I have managed to convert to do this.

      It was done, by adding a class called area that has an object called Area Control... If you want to see a version of this installation the tables I had to change for modules and blocks to be installable on all versions and some on one and none on the other was:

      newblocks - area varchar(255) latin1_swedish_ci YES default
      group_permission - gperm_area varchar(255) latin1_swedish_ci YES default
      config - conf_area varchar(255) latin1_swedish_ci YES default

      The fields that where produced are next to these

      The xoops object has to associate an area or domain like for example http://massage.uk-therapist.co.uk/ and http://uk-therapist.co.uk/ and http://uknaturalhealth.net are all the same xoops, same prefix.

      an area is like in the database as "default" for system object the rest reflect the subdomain or domain they where set up on..

      Corresponding with domain_config table.

      I am using for example an extension on the sql query to isolate with an IN ie. gperm_area IN ('default','uknaturalhealth') which in code looks like .' AND gperm_area IN ('default','$_area->area')'

      The area class gets declared in mainfile.php..

      I have started working on a forum for it in Core Hacks in www.xoops.org, but the code there is old but you can get the idea from it.


Log in to post a comment.