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
Dependencies
  • I think here must be 2 'main' Kohana modules - Auth and Forge. What is your thoughts about it?
  • Hi utyf.

    What do you mean by 'main' ? Can you be more precise ?
  • As we want to built an administration an or the auth module is highly required.

    Personally, i don't use Forge but if the most members use them... Maybe we can create two Demo_Controller, one with and one without Forge.
  • 'main' are modules, that are included in Kohana package. I don't use Forge too, but think, that its usage is common practic for Kohana apps.
  • I don't use Forge too. That makes 3 of us only in this topic. So, it is really a main module ? ;)
  • I think we should ignore the K2 Auth module and write our own. :)

    Regarding forge... it's not wonderfully strict MVC so I'm dont sure it's the best thing to use :) maybe our own form library?

  • What do you guys think of this?

    http://code.google.com/p/authoreyes/source/browse

    Edit: It's not that close to being done, but I've done a lot of testing and think that opening it up to you guys might help finish it quicker.
  • - Yes, Forge is not so popular library, as I thought:)

    - Errant, explain us your opinion about Auth.
  • I use Forge, and right now its pretty good for my needs.

    And, i think, if we wanna make a Kohana Style starting point we should use the Module / Library installed in the core, or make new ones but they have to be Kohana's later...
  • Yeh but remember Forge and Auth are Modules packaged with the framework... not really part of the core. :)

    Certainly the Auth module is unsuitable for our needs (with the amount of stuff you need to add to it to make a decent scale ACL it might as well just be rewritten :P)

  • I think we doesn't need an extra form/forge lib while kohana is serving one. If most of us doesn't use it, Hanami doesn't have to in it's own "core" but if a programmer feels comfortable extending the module controller in his app with forge, he can use it... app logic doesn't depend on how the output is generated...
  • I also dont use forge, plus im in love with the svn;s validation system :).
    Also i kind of agree that it would be cool to build your own Auth library, maybe something with more options. That a role system could easily be plugged into.
  • Sure, this will be a great plus.

    So do we start with the auth module? Something new or based on the existing one?
  • I think you could start it yourself, maybe setout like.
    Auth
    Auth_ACL
    Auth_Roles
    Auth_Profile (if you wanted to extend it)

    ofcourse you could take over some of the code but i think starting afresh is always the best solution.
  • hi, just wondering is Hanami going to use the stable relase of Kohana or the latest from SVN?
  • I just suggested that Hanami always should use the current stable release. I think there is more solid documentation and less risk that way.

  • I think Hanami should use SVN, because otherwise you're going to be left in the dust when 2.2 comes out and you have to rewrite large parts of your app in order to upgrade. Besides, if you're doing a project this big, you should already be somewhat familiar with Kohana source, and should be comfortable keeping up with changes.

    Benefits to using SVN:

    • New Validation
    • New driver-based Auth
    • upload and file helpers
    • Lots of core optimizations that will never be seen in 2.1.x
  • @Shadowhand, i second that... :D
  • dito... hanami must use svn
  • I think we should listen to Shadowhand and use svn. however I'm not sure what that means.. is it this one: http://trac.kohanaphp.com/browser/branches/2.2-database ?

  • thank you Dyron.

  • i use forge... at first i didnt simply because i thought to myself "why would i need a library for creating forms, those are easy!"

    but after actually using forge, i found its simple awesome, i ended up extending it and tacking on jquery validation. but i can now add a single line of code to cover adding, editing, saving, and validating any input from a form... thats a lot of power we wouldnt normally have.

    my only issue with forge, is it doesnt use the validation library, i think the idea is perfect, but probably could be done better to actually leverage the power of the validation library, not just the valid helper

    also, unbiased opinion of using kohana 2.2.... while yeah sometimes the specs change, i throw a rss feed of kohana's trac timeline into my rss reader to keep up on whats happening(alot of it is language updates), and with the exception of one occasion in the past several months(they changed how sessions work, was an easy fix of just updating my config file), no change from the trunk has broken a site i've developed

  • Forge is really good if you just want normal 'straight' forms. My problem with forge is that I often want to 'get creative' and modify the form slightly (often making it dynamic in some way) and then I have to create a whole new library item that will only be used this once, instead of just writing a few lines of code. Forge is also very secure.This has created a lot of frustration for me. I find it great if you just have the need for an occasional form but I don't think it's the right tool as a centrepiece for an admin application..I have tried and it has been very time-consuming.

  • As the creator of Forge, I'll say this: Forge works great, if all you ever need is 1 input per line, 1 submit button, and 1 form per page. Beyond that, it starts to be more hassle than it's worth. Personally, I use Validation in my ORM models now, and just write my forms by hand. I find it less time consuming than trying to hack Forge to do what I want, and in the end, the code is faster.

  • 2.2 is definitely the way to go. There are too many enhancements to the codebase to ignore.

    Since Auth is such a major part of Hanami and many other Kohana applications, perhaps a collaborative effort by the Hanami team to enahnce the existing Auth module that can be contributed back to the Kohana core would be useful -- reviewed by the Kohana devs of course.
  • *..a collaborative effort by the Hanami team to enahnce the existing Auth module that can be contributed back to the Kohana core would be useful...**

    A very excellent idea. It seems like a waste to not work on making Auth better rather than trying to start from scratch. All I ask is that a driver-based system be maintained, so that people can choose to implement different backends, even if Hamami only provides one backend when contributing it back.

  • I think that validation in the model is the way to go to

  • I think that its only fair that Hanami gives something back to Kohana since plenty has been going the other way :)

  • I think this:

    Forge works great, if all you ever need is 1 input per line, 1 submit button, and 1 form per page. Beyond that, it starts to be more hassle than it's worth

    should be added to the top of this doc page Would have saved me a lot of trouble....

  • Just chipping in. Absolutely agree that you base your code on svn and keep up with it, not using svn would shortchange your project and be too much work to upgrade later.

    I normally code things manually, like forms (or use the form helper). I recently started using Forge, and it is a wonderful time saver.

    If you were coding a website application, I would say use Forge, (or other similar libraries), but because you are building a CMS, which needs to efficiently produce application output, I would strongly suggest staying away from this kind of code-generator. Code the stuff manually, or using helpers, models or whatever and you will be able to adapt faster, be more flexible and efficient.

    Regarding Auth, it's of course your decision, I will only add my emphasis to the requests that you extend or enhance what is available from Kohana, rather than building from scratch.

  • While on the topic of Auth. It would be interesting to see a list of the weaknesses in the existing Kohana Auth module. Here are a few things to get started:

    • Should be able to configure table names via config instead of hardcoded "users", "roles", "users_roles". --- although these table names should be sufficient for most users.
    • Implementing a groups system to compliment the roles would be nice as well. Where roles can be assigned to groups and users assigned to groups (inheriting all of the roles assigned to the group). A default group (e.g. "user") can be used when full group functionality is not required for an application.
    • A basic scaffold for user management, password reset, etc.
    • Probably not useful for Hanami, but maybe drivers for OpenID, .htpasswd, text file (csv)


    * Just my opinion, but if you can avoid using the acronyms -- ACL, ARO, ACO, etc. in the module, it will save a lot of support issues down the road :-)
  • Should be able to configure table names via config instead of hardcoded "users", "roles", "users_roles". --- although these table names should be sufficient for most users.

    This is irrelevant in the SVN version, because Auth is driver-based.

  • Reading pros n cons of Forge...
    I heard Formation has some nice validation stuff. How does Formation compare to Forge+svn validation?
  • Never looked deep in Formation, i think, it uses build in validation and is comparable to Forge + Validation (a bit less writing).
  • Formation is comparable to Forge as it also generates forms. It uses its own validation library though which can be used on its own. Rules are objects so can easily be extended and added to. It supports re-ordering of form elements, partial validation, jquery client-side validation, groups, built-in error messages, filters and callbacks. Error messages can be completely customized so. It also comes with Model_Formation which is a library to turn your ORM models with rules into forms with three lines of code. I use that functionality for my backends to quickly generate them. The idea for this stems from Django.
  • dont mean to hi-jack the thread but one quick question since we are on the subject of Formation, @dlib - is there any plans to add the Formation lib as a module to Kohana SVN?
  • Since Forge is already available and Formation also changes some ORM related stuff I don't think it's feasible to add Formation as a module to Kohana.

Howdy, Stranger!

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

In this Discussion