Time to release #nettefw 2.1 is coming
- David Grudl
- Nette Core | 8227
I would like to solve these issues (plus add another cca 5 features) and release version 2.1<. Together with Nette will be released stable Nette Tester.
What will bring the new version?
- Presenter: secured links
- PresenterFactory: configurable mapping Presenter name → Class name
- Route: new pseudo-variables
%basePath%
,%tld%
and%domain%
- Dependency Injection:
- annotation @inject
- auto-generated factories and accessors via interface
- adding compiler extensions via config file
- auto-detection of sections in config file
- configurable presenters via config
- simple validating schema
- Database
- complete refactoring, a ton of bug fixes
- lazy connection
- much better (dibi-like) SQL preprocessor
- all queries are logged (error queries, transactions, …)
- new driver for Sqlsrv
- Debugger
- Dumper: colored and clickable dumps in HTML or terminal
- Bar: you can see bar after redirect and is updated via AJAX
- full stack trace on fatal errors (requires Xdebug)
- Forms
- new macro
n:form
,<select n:input>
and<textarea n:input>
- partially rendered radiolists using
{input name:$key}
and{label name:$key}
- setOmitted: excludes value from $form->getValues() result
- removed dependency on Environment
- improved toggles
- improved netteForms.js
- new macro
- Latte
- short block syntax
{#content}
- macro {link} generates URL without presenter
- a lot of small improvements
- modifier
|noescape
- short block syntax
- RobotLoader: on-the-fly filters
- SmtpMailer: persistent connection
- Json: supports pretty output
- added new SessionPanel
Do you know about something important, what should be added to or removed from 2.1?
- Jan Tvrdík
- Nette guru | 2595
@David Grudl: I still believe that
@property
annotation should be added back to
SystemContainer
(revert 4a1ce4).
I understand that in theory DI container should be used only in composition
root, but for practical reasons (lots of apps using it now, great for
prototyping, less writing than proper injecting), we should keep the
@property
annotation. I suggest we continue this discussion under
the related
commit.
- Majkl578
- Moderator | 1364
I hope there will be proper beta/rc phases as well as their tags on GitHub. Not the way how 2.0.x versions are released (no tag, just some archive somewhere which noone actually will test, since it can't be pulled by composer).
These are things I think are worth fixing before release:
- Cache::ALL smaže celou cache, ne pouze namespace
- Latte: “pretty output” is actually ugly
- This ugly thing (see comments)
- Fix 90c6c851 (see comments)
- Fix d4418f01 – Session::regenerateId() called explicitly should really regenerate id
- Reconsider 27435fad having as property (see comments)
- See 6b0b1ff6 – add this to Sandbox?
- Fix 0e79764f – both BOM removal and mbstring dependency (add to composer?)
- Reconsider 1bc4260a – it pollutes global namespace, debug() is worst of them (see discussion)
- enumag
- Member | 2118
Authorizator won't be fixed? It's pretty much useless in current state (for me at least).
EDIT: Just noticed that it actually is in the 2.1 milestone on GitHub. But I'm still little confused since it isn't mentioned in the list above.
Last edited by enumag (2013-04-16 22:58)
- David Grudl
- Nette Core | 8227
- @property: I'll be think about it
- Cache::ALL: prepare pull request
- Latte: “pretty output”: dtto
- This ugly thing: dtto
- REGENERATE_INTERVAL: was removed from framework
- add this to Sandbox: ok, prepare pull request
- debug(): will be removed
- Authorizator: will be in 2.1
- nanuqcz
- Member | 822
- Database: Will be multi-related function supported?
foreach ($article->related('article_tag:tag') as $tag) {
....
}
- Database: Will be SqlLiteral in select() supported?
$db->select('*')
->select(new SqlLiteral('AES_DECRYPT(secured_note, ?) AS secured_note', $aesPassword));
These are only two things I am waiting for in Nette :-)
- Majkl578
- Moderator | 1364
David Grudl wrote:
- Cache::ALL: prepare pull request
- Latte: “pretty output”: dtto
No idea how to fix these. Lets discuss it in those issues if needed?
- This ugly thing: dtto
I provided a different solution, @enumag another one (neither of these wasn't polluting public API), but you rejected them without discussion…
- enumag
- Member | 2118
@bene:
All Nette services should have nette prefix.
Addition of the prefixes is more complicated than you think. Adding aliases is not enough because it won't work in all cases. We already tried it, it was even merged once but had to be reverted soon after. Basically we don't know how to do it without braking back compatibility yet. See my pull request for details and discuss it there.
About Context @property I don't understant why anotation is problem if magic methot __get() allows access to services?!
Feel free discuss it here.
Last edited by enumag (2013-04-18 23:08)
- bene
- Member | 82
About Context @property I don't understant why anotation is problem if magic methot __get() allows access to services?!
A lot of classes in Nette has @property anotations because has getXyz() method and extends Nette\Object. Why is the Container different?
Nette\Security\User miss anotation @property-read IUserStorage ;-)
@enumag: I've read discussion about services prefix (I confess I didn't deep study this problem) bud Davids comment is about same service in config. Uncompability in config is little problem I think.
I've read discussion about @property
and should I worry about
reject magic method __get()
from Container
? Back
compability is easy, create my own Container
which will be
implement magic __get()
method. But I think all peaple who have
benefits from magic __get()
method will be implement own
Container
and this “mistake” will by solved only for new
programers.
- enumag
- Member | 2118
@enumag: I've read discussion about services prefix (I confess I didn't deep study this problem) bud Davids comment is about same service in config. Uncompability in config is little problem I think.
No it isn't. It's huge BC break. And don't discuss it any further in this topic please.
Same for the @property. Discuss both on GitHub or create a separate topic(s) if you don't have a GitHub account.
Last edited by enumag (2013-04-19 00:03)
- enumag
- Member | 2118
Will these be in 2.1? (They should in my opinion.)
Also what about this?
Shouldn't this one be in master for testing purposes?
- Honza Marek
- Member | 1664
Deprecated $form->onSubmit
should be removed in next version.
In autocompletion list it is before onSuccess and I make a mistake almost on
every attempt on submitting a form ;)
- Majkl578
- Moderator | 1364
Honza Marek wrote:
Deprecated
$form->onSubmit
should be removed in next version. In autocompletion list it is before onSuccess and I make a mistake almost on every attempt on submitting a form ;)
It is not deprecated, it is an event that occurs always, even when submitted an invalid form.