Feature Requests / Missing Features

tobsn commented 13 years ago

better debug settings: dev vs. production settings, maybe some nice output of whats going on (kinda like in the logger right now - maybe support firephp?)
autoload controller/model/view: see the examples i sent you and maybe look into how fuel & node.js frameworks/router/dispatcher handler this problem (http://fuelphp.com/ & https://github.com/ry/node/wiki/modules)
database model: see what i sent you and activemongo (for mongodb)
based on database model -> pagination!: see fuel pagination class
security: see what i sent you with database model & roles
language support: http://www.php.net/manual/en/book.intl.php

codeguy commented 13 years ago

Better debug settings

Agreed. Will think on this and post some ideas here later this weekend after 1.1 is released.

Autoloading controllers, models, views

Maybe. Slim is a very small framework that makes as few assumptions as possible. Will checkout your links tomorrow.

Database Model

Probably won't happen. I've purposesly chosen to exclude an ORM from Slim. There are a lot of nice ones to choose from already... Paris/Idiorm, Recess Framework's ORM, etc.

Pagination

Dependent on the ORM. I wrote a pagination (based on @nunemaker's Plucky paginator) at https://github.com/codeguy/Recess-Framework-Model-Pagination

Security

Slim could benefit from an authenticate plugin similar to Rails' Devise. I've been meaning to write one soon using the new plugin/hook system.

Language Support

Agreed. I need to research this some for my own benefit and then implement support into Slim.

bobdia commented 13 years ago

Better debug - yes

Autoloading

I think most people are following the proposed standard: http://groups.google.com/group/php-standards/web/psr-0-final-proposal . I think that's the only thing we need and only implemented for the core of Slim. Then if anyone wants to implement custom autoloaders, they can work with that or write their own.

SplClassLoader in PHP: https://gist.github.com/221634 , and as an extension: https://github.com/metagoto/splclassloader

ORM/models/pagination/

I don't think Slim needs and ORM at its core.

Security

Devise for Rails looks very useful, something similar for PHP would be great. I plan on writing (maybe in the coming week) a small auth plugin for my webapps, but it will be nowhere near the scope of Devise. Just something simple with a couple HTML forms and a SQL backend for storing credentials.

Localization

A story to consider:

http://search.cpan.org/dist/Locale-Maketext/lib/Locale/Maketext/TPJ13.pod#A_Localization_Horror_Story:_It_Could_Happen_To_You

(some discussion: http://news.ycombinator.com/item?id=2095334)

Caching

A caching utility with adapters for various storage systems would be great, along with some degree of integration with core Slim.

codeguy commented 13 years ago

@bobdia

Some thoughts and questions for you:

I've resisted it so far, but with the addition of more class files I am seeing the benefits of using the autoloader pattern where class names are namespaced with underscores. I don't want to use PHP 5.3 namespaces to maintain PHP 5 < 5.3 support.
I'll likely write an authentication plugin based on the Warden RoR gem. Provides a high-level authentication framework that still enables the developer to define application specific strategies for auth. This will not be a Core class, but instead provided as a plugin in an extras/ directory.
How do you see Localization implemented into Slim's Core? The only language output within the Core classes are Exception and Error messages. How else do you see Localization being integrated?
Caching... can you provide some examples for integrated caching? Route output memoization was suggested on the Issue Tracker. Was wondering what other examples you might have. Do you see this acting much like the new Logging system (ie. provide your own Cacher which Slim will use if available)?

rlm80 commented 13 years ago

Hi,

I'm not really THAT good at PHP (it's a hobby, it's not my job), so take my words with a grain of salt.

I really like the framework's philosophy of keeping it as small as possible to that people can choose whatever tools (ORM...) they like to work with best.

That's why I would advice against the point "autoload controller/model/view". It's fine to use autoloading for the framework's own classes, but providing such a mechanism for user classes goes against the philosophy of the framework IMHO. Some people like to put their classes here, some people there, some like underscores, some prefer namespaces and so on.

Beside, it's really easy to add one's own autoload function in the bootstrap file. Something along the lines of (not tested) :

spl_autoloadregister(function($class) { require [my classes folder] . strtr($class, array('' => '/')) . '.php'; });

Maybe providing such an example in the docs would be good though. Since most frameworks have that feature built-in, newcomers are bound to ask you why it's not there and how to add it.

BTW and on an unrelated note, I think the syntax... Slim::route([route name])->url([url params]); ...would be more elegant than the current Slim::urlFor() function. Matter of taste though.

Thank you for your great work on this.

codeguy commented 13 years ago

@rlm80 Thanks for the feedback. Re: your Slim::route('name')->url(...) suggestion, I like it. There's nothing keeping me from implementing it alongside the current Slim::urlFor() helper method.

bobdia commented 13 years ago

@codeguy

One advantage is that other people that have autoloaders compatible with the proposed standard, can just drop Slim in their /vendors directory and have it work for them.
Let me know if I can help with that.
I'm not sure what my point was, perhaps that no localization is more desirable than bad localization. It's important to have for plugins however, so we could borrow a few ideas from MakeText and see what we can make of it.
Again, this is very much needed for a good plugin platform. Something simple like Slim::cache('key', 'Lorem ipsum') should suffice. If we go with pluggable cache engines then we also need Slim::setCache('engine', $options).

DarrenN commented 13 years ago

would donate beer money for a good Warden port to PHP usable in Slim.

tobsn commented 13 years ago

https://github.com/jsmestad/sinatra_warden/ like that? i already build a simple hook to do role based auth... i could just gist the thing...

DarrenN commented 13 years ago

Devise is the 'gold standard' as it comes along with views, etc. But having a solid foundation like Warden as a plugin would be fantastic (using phpass http://www.openwall.com/phpass as the hashing algorithm). Authentication is one of the things I dislike having to implement, but always have to have.

Also, +1 for the Autoloader. I'm currently using the Namespace spec that @bodia mentioned but its causing all kinds of problems with other libraries I need for my project so I will probably ditch it. Slim's built in is nice, and Twig has it's own, I just need a clean way to load my models and other libs.

bobdia commented 13 years ago

I agree with adding some default views to the auth plugin. Speaking of phpass, I've made a PHP5-only implementation (it needs a couple improvements though):

https://github.com/bobdia/php-otp/blob/master/PassHash.php

codeguy commented 13 years ago

@All Thanks for the great ideas. I'm definitely listening. Will re-organize the roadmap with your ideas once I get some free time later this week.

Calvein commented 13 years ago

I think it could be a good idea to add a parameter of the Slim::urlFor() method to inform what HTTP method we would like to use, especially for the DELETE one when you don't need a form but just a link. Instead of simulate the delete in JavaScript, by creating a form, it would be nice to be allow to do something like this : Slim::urlFor('maRoute', array('id' => $id), 'delete')

codeguy commented 13 years ago

I'm not sure I entirely understand. In either scenario, Slim::urlFor will return the URI (with URL segments populated) of the named route. The HTTP method is entirely up to you based on how you initiate your HTTP request. Can you tell me what you would expect returned from your example above?

Calvein commented 13 years ago

I would like to do only one name for my GET/POST/PUT and delete routes. I just want a link to perform my DELETE route, the problem is that Slim::urlFor('myRoute', array('id' => $id)) will always go in the GET route. If I want my link to perform the DELETE route, I have to catch the click event on my link and simulate a form like this :

$('.destroy').live('click', function(e) { e.preventDefault(); if (confirm('Êtes-vous sur de vouloir supprimer ce document ?')) { var $this = $(this), $form = $('

').appendTo('body');
$form
.attr({
method: 'POST',
action: $this.attr('href')
})
.hide()
.append('')
.find('input')
.attr({
'name': '_METHOD',
'value': 'DELETE'
})
.end()
.submit();
$this.parents('tr').fadeOut();
}
});

So I thought I could be nice to have a parameter in urlFor to choose wich route we want to use.

codeguy commented 13 years ago

@Calvein Gotcha. Right now Slim does not have a concept of resources, or a collection of routes that compose a resource; this is under consideration and may appear in the future. So as it stands, you'd have to manually add Javascript/jQuery (preferably with event delegation) to accomplish this. The script below is only needed once for an entire table of rows.

$('#my-table').delegate('a.delete', 'click', function (e) {
    e.preventDefault();
    $.ajax({
        url: $(this).attr('href'),
        data: {
            '_METHOD': 'DELETE'
        },
        error: function () { ... },
        success: function () { ... },
        type: 'POST'
    });
});

Hope this helps in the short term.

CoolGoose commented 13 years ago

Hi guys, I was wondering if a feature like Padrinorb's "mount" for apps/modules would be nice in slim

https://github.com/padrino/padrino-framework/blob/master/padrino-core/lib/padrino-core/mounter.rb

Basically it allows you to split your items in distinct chunks :P

tobsn commented 13 years ago

@coolGoose: example?

CoolGoose commented 13 years ago

@tobsn

http://www.padrinorb.com/guides/mounting-applications

Calvein commented 13 years ago

I think add the urlFor method in Slim_view could be useful to allow us to do $this->urlFor() in templates in 1.5.

silentworks commented 13 years ago

In the current version in develop branch you can do $app->urlFor(); which is as good as $this->urlFor().

tobsn commented 13 years ago

im gonna go ahead and close that one so someone can open a new one with new features because this one is already half a year old ;)

slimphp / Slim