TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
What is Hanami Mission statement or Goal?
  • This is probably the most important thing we have to do right now as everything else depends on this.
    This tread is for continuing the the discussion on what Hanami is going to be.

    What we are after is a plain english description that can set everybody on the right track. I have an idea about this of-course, but no time today to write it down.
  • Here is my 'work in progress' definition for the Hanami CMS project

    • Hanami is a simple generic starting-point for a CMS. The most basic and commonly used cms features should work out of the box. Hanami is about speeding up the development process.
    • Hanami is driven by the Kohana community. (note: not the core kohana devs, this is a separate project from Kohana).
    • Anyone can contribute as long as they follow the co-operation guide-lines (yet to be defined).
    • Hanami is built with the Kohana framework using Kohana 2.1.3
    • Hanami should have an upgrade policy. How do we keep up with the changing releases of Kohana.
    • The Hanami project aims at allowing developers to get started (and finnished!) more quickly than if you started from an 'empty' Kohana download and still use their beloved Kohana toolbox.
    • Hanami is modular.
    • Because Hanami is a common context and modular Hanami can be a place for developers to share code an avoid that everyone has to 'reinvent the wheel'.
    • Hanami is place to share good coding practice and learn from each other.
    • Hanami will use convention over configuration.
    • Hanami has to be relatively simple 'Tools that you don't understand are of no use'.

    The more precise and detailed we can make this list the easier it will be to realise I think. Please add or subtract bulletpoints. All your other posts are not forgotten I just haven't had time to traverse them all and extract all the goodies.

    UPDATE: There is common agreement on using Kohana svn (trunk) instead of Kohana 2.1.3 that I have listed here

  • Posted By: mkjems

    Hanami is built with the Kohana framework and should aim at always working with the latest version of Kohana.



    Let's point to the 2.1.3 or 2.2 system tag as external link.
  • good point Dyron I had not thought about that. Hanami should have an upgrade policy. How do we keep up with the changing releases of Kohana? I think that this is what will force us to keep Hanami 'Lean and Mean' because people will want to use the latest stable version of Kohana and so Hanami will have to work with the latest stable version. If Hanami is to complex and falls behind then it will be useless.

  • I'll try to replace the existing system folder with the external..

    I think, if Kohana releases a new stable version, one of us should rework the differences and checks out the new working one. Maybe we can close the svn trunk branch for that or create diffrent tag lines...
  • Another note:

    Maybe we should leave the trunk/frontend/config/config.php an trunk/backend/config/config.php not under the svn, while everybody handles his own webserver/domains/folders himself. The devs should know, how a kohana app gets runnning. ;)

    The installer of main app can create them on a production ready site.
  • Maybe we can close the svn trunk branch for that or create diffrent tag lines..

    I agree, we should have tag lines that correspond to the Kohana version that Hanami extends/works with

    UPDATE:

    TODO: create tag linesin svn that correspond to the Kohana version that Hanami extends/works with.

  • Maybe we should leave the trunk/frontend/config/config.php an trunk/backend/config/config.php not under the svn

    I agree, The devs can handle them differently.

    UPDATE:

    On second thought... is it not better that the standard config.php is in the svn but renamed 'config.example'. Then each dev can copy that to config.php and fill it with local data. ...still not 100% about this.

  • regarding checkins and updates I rather like Mozillas approach to it.. they have (basically) 3 scenarios.

    1) Free-for-all: and dev can check into the tree 2) Engine upgrade: the tree is locked for a single (or a couple) developer to perform compatiblity updates 3) Release lock: the tree is locked to allow the releases team to clean, package and archive.

    The stricter the approach to this the easier code will be to keep clean. Obviously we wont have the automatic tools they have - but it might be a nice approach!

    If we have a roadmap of features that says "when we get to this situation the tree will be locked and x,y,z devs will package the tree together", then when Kohana roles out updates or changes the API etc. in a way which breaks Hanami we can just post about a lock.....

    But that's just an idea :P

    Regarding the CFG I agree with mkjems idea of config.example.php (or some sort of example somewhere nearby), it will be a fairly big help IMO. Especially if we add in any of our own vars into the cfg or anything :)

    Because Hanami is a common context and modular Hanami can be a place for developers to share code an avoid that everyone has to 'reinvent the wheel'.

    I like that one (one of the thigns I have framed on my wall is "no probelm should have to be solved twice")

    idea would it be cool to put together a short (3 or 4 word) tagline for Hanami that sums it up in a sentence? Gives the devs something to think about when coding :D

  • I like the idea of "qualitymanagement", so a few people observe the code and merge it inside the trunk line.

    For bigger modules we can handle an own branch line for that, after finishing merge it to trunk (like Kohanas /branch/2.2-database). So at first we should create an branch for the basic install app based on Edys one :).
  • ideaGDN would it be cool to put together a short (3 or 4 word) tagline for Hanami that sums it up in a sentence? Gives the devs something to think about when coding :D

    Hey what is wrong with the incredibly sexy: "a community driven generic startingpoint for a CMS built with the Kohana framework" that is our current tagline? LOL ! Not sexy but quite descriptive wouldn't you say.

    if you have better suggestions we can change it, no problem :-)

  • Idea...

    "Hanami, Kohana has blossom" :D Or something like that
  • We should follow the Kohana principles:

    "A community driven fast, secure, lightweight CMS made with Kohana". We don't want a starting point, we want a working CMS app!
  • Sorry mkjems I didnt see that you'd put that there :P apologies.

  • no need to apology I was just trying to be funny!

  • I guess we should all remove trunk/frontend/config/config.php and trunk/backend/config/config.php

    from version control.

    trunk/frontend/config/config.example and trunk/backend/config/config.example is there to create a local version for your setup.

    While I understand the need for some flexibility I believe that the simpler we make installation and the more alike we make our code the better.

    remember 'convention over configuration' :-)

    let's try to stay together from now on...

  • I wrote a short 'installation howto' (middle of the page)

    Please verify :-)

  • I guess we should all remove trunk/frontend/config/config.php and trunk/backend/config/config.php

    There's a problem with that. The installation app wont work without a valid config file... any ideas for a solution?

    (we need somethign to install as well :P)

  • config.php in the installation app should work everywere.

    And the installation app creates both config.php files.
  • Yeh cool: which means we need an install.php file ofc (which isn't there yet) and some sort of tweaking to the .htaccess

    coming back to my previous comments of "how many apps are we ending up with?"

    (sorry playing devils advocate as much as poss).

    Also thinking about that both the admin.php and index.php will NOT work till install has been run: so you're going to get nasty 404 errors and lots of hell all over the place till you visit a specific URL. So perhaps admin.php and index.php should load the installation app at the start (eg $kohana_application should point to installation) and the installation process edits those files to change it to the correct place... (could hit issues with file permissions there!).

    Just throwing thoughts out there :D

  • Posted By: Errant

    Yeh cool: which means we need an install.php file ofc (which isn't there yet) and some sort of tweaking to the .htaccess



    No, if IN_PRODUCTION is false hanami loads the installation app.


    $kohana_application = IN_PRODUCTION ? 'hanami/frontend' : 'installation';


    Change admin.php that way too? After installation IN_PRODUCTION must overwritten to true.

    Besides after that, you can't access the Installation_Controller because of the first line:


    <?php IN_PRODUCTION and die('Installation succeeded.');
  • I think IN_PRODUCTION is a bad name. IS_INSTALLED is more descriptive of what is going on. Once Hanami is up and running the developer using it to create a site will properly want to switch the site between two modes: PRODUCTION, DEVELOPMENT.

  • How are the two modes different to each other? other config/log/error_reporting? This can the dev set himself after loading files form the svn trunk.

    IN_PRODUCTION says that the website is ready for use independ of the mode.


    Maybe the Hanami hook is a place for decide PROD or DEV mode.
  • I thought that removing trunk/frontend/config/config.php and trunk/backend/config/config.php was something we did for practical reasons while we are developing Hanami. Dyron wanted to have a different version of his config/config.php so I said fine... :-)

    To tell you the truth I'm really not to glad about all this focus on an installer..I think making an installer is something we can do later on ... not the first thing we should do...right now its just creating problems for us...

    I think we should just write an installation guide and all do it the same way. Keep the code the-same-for-all-developers and leave this installation 'problem' alone for now.

    Edys cms allready has this problem solved (I have not studied it yet) so if we want an installer, we could probably analyse his example and learn how to do it.

  • This should not be an installer for devs. Like i said Hanami devs should at least know, how a Kohana app will be installed rather then knowing read the introduction docs for devs where you tell them how.

    My installer targets the user installation means server data, license agreement, database and optional some sample data. I see that this thing should be not one of the first things to do.

    Well, maybe the database design comes first beside we have to declare which basic function the Hanami hook and the Hanami module provide.
    Basic frontend and backend controller, auth, acl, content management?, static content pages?

    We have to discuss how our basic Controller looks like, how the templates are filled and so on.

    What do you thing of the idea serving XHTML to clients which it understands and HTML to the IE?

    And yes finally we have to discuss how our (X)HTML output look like. Used IDs, classes, elements.
  • What do you thing of the idea serving XHTML to clients which it understands and HTML to the IE?

    I dont get that? Pretty much all browsers in use today support the Xhtml syntax.. even IE6 recognises it. I assumed we would be using standard Xhtml semantic layout..... The difference between Html 4 and Xhtml 1 is not major :)

  • i think that Dyron is talking about serving xhtml as application/xml+xhtml to browsers that support the standard
  • To me you should just go with HTML unless you are using 100% XSLT, which alot of people arent overly familiar with, so it could be alot harder.
  • Serving with application/xml+xhtml and accepting user input with comments, content management has the excellent feature that if the user doesn't abide to xhtml syntax (and leaves a closing tag or whatever) the whole page will not render. So, make sure the content management filters translate input to acceptable xhtml.
  • I suppose, it does server for cleaner code :P, and ive always loved the tag precedence move they made :).
    I guess i would just need to learn some XSLT :)
  • Oh ok.. I'd say just stick with standard Html.. unless someone comes up with a convincing solution that will allow a way to disable that on the fly for customised content/views (bearing in mind that the majority of developers may well not write strict Xhtml and therefore end up with blank pages they dont understand :))

  • I say let's stick with standard if no-one has a good reason not to:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd">
    

    I think that as a default Hanami should add a link to http://validator.w3.org/ at the bottom of every page. I use this:

    <a href='http://validator.w3.org/check?uri=".urlencode($_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"])."&charset=%28detect+automatically%29&doctype=Inline&group=0'>Validate HTML syntax</a>
    

    I find that really usefull in development

  • Humm, just curiosity, but why transitional and not strict?
  • What is going on in the svn ? I'm sorry if I have stopped Dyron halfway through his installation program and now we are left with some halfbaked cake... :-)

    How about if we do this: * All hanami devs should set up their local hanami site the same way (follow some common installation instructions posted in the wiki) this means doing away with config.example * we all use the same config.php and the same index.php and admin.php and remove the beginning of the installer code

    This way we will all be able to run 'svn update' with-out breaking the local site... Does this sound ok , or am I missing something....

  • Well, i would stick to HTML 4.01 Strict, too.


    In addition, such a link is unnecessary, while "normal" users doesn't matter. Valid HTML doesn't have to be semantic, but that's my and hopefully one of Hanamis goal.


    Edit:

    I don't think the trunk/ iss wasted with parts of the installation branch, while just leave the branch alone and reuse it when it's time.
  • @ Dyron I really think that the installer is a nice idea that we can implement to give Hanami 'wings' once we have something that actually does something :-).

    I just don't think that an installer is central to what Hanami is all about and therefore not a place to start. I really like your energy and hope that you don't feel to bad about this.

    What i think would benefit Hanami is if we find a efficient way to collaborate and hence the above suggestion... I wonder how the Kohana core team sets up their project ?

  • after reading you comments and this I think that strict is the way to go:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
    
  • Posted By: mkjems

    @ Dyron I really think that the installer is a nice idea that we can implement to give Hanami 'wings' once we have something that actually does something :-).

    I just don't think that an installer it's central to what Hanami is all about and therefore not a place to start. I really like your energy and hope that you don't feel to bad about this.



    I'm not feeling bad, while sharing your opinion now. I see that an installer is not the way to start. I think i have a good module/plugin way, but it has to be more detailed before publishing.
  • Sorry why not Xhtml 1.0 transitional or strict? There is no difference betwqeen the 2 and the second is more standard compliance.

    Html 4 is OLD school and doesn't equate any more! (I originally thought this discussion was about the DTD and whether to go with a Xhtml or Html 4 declaration... I then got told it wasn't.. is it or isn't).

    In the vast majority of modern browsers Xhtml 1.0 Strict (not 1.1 note) and Html 4.0 render EXACTLY the same: so why not stick with Xhtml :)

    re the SVN: i stopped adding content till we had more "focus" I guess :P Maybe if we all took on a specific piece and got that done then moved to the next: then we can use the trunk (always a good idea IMO) w/o clashes :)

  • Posted By: mkjems

    Hanami is a simple generic starting-point for a CMS. The most basic and commonly used cms features should work out of the box. Hanami is about speeding up the development process.



    Thinking about that over and over again I conclude Hanami is a bundle of lib, models, views. My intention is to create an basic functional, easy extensible CMS a basement for my and even your projects.



    Posted By: Errant

    Sorry why not Xhtml 1.0 transitional or strict? There is no difference betwqeen the 2 and the second is more standard compliance.

    Html 4 is OLD school and doesn't equate any more!



    I always vote for a strict type. But if we use XHTML i prefer sending it as application/xml+xhtml like suggested in the specs.
    What's about writing HTML 4.01 on XHTML requirements? Afterwards we have to change only the doctype if we are ready for XHTML sendind as application/xml+xhtml. You have no disadvantages using HTML 4.01 strict and it's not outdated.
  • Posted By: mkjems

    good point Dyron I had not thought about that.
    Hanami should have an upgrade policy.
    How do we keep up with the changing releases of Kohana?
    I think that this is what will force us to keep Hanami 'Lean and Mean' because people will want to use the latest stable version of Kohana and so Hanami will have to work with the latest stable version. If Hanami is to complex and falls behind then it will be useless.



    You could try and keep up with the latest version or you could take a more conservative approach and opt for stability over a the latest version with a rich feature list. For example, Fedora is a cutting edge linux distro but not very useful in the enterprise space whereas slackware is a bit behind but solid and reliable. A good quality api and some useful hooks would make a CMS very useful indeed.
  • You could try and keep up with the latest version or you could take a more conservative approach

    I agree with this, but highly recommend that you use the 2.2 series, since 2.1 will be outdated and unsupported very shortly. The 2.2 branch should have 4-6 months of life, if not more.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion