Time to release #nettefw 2.1 is coming

7 years ago

David Grudl
Nette Core | 6886
+
0
-

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
  • Latte
    • short block syntax {#content}
    • macro {link} generates URL without presenter
    • a lot of small improvements
    • modifier |noescape
  • 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?

7 years ago

Jan Tvrdík
Nette guru | 2563
+
0
-

@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.

7 years ago

enumag
Member | 2128
+
0
-

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)

7 years ago

David Grudl
Nette Core | 6886
+
0
-
  • @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

7 years ago

nanuqcz
Member | 844
+
0
-
  1. Database: Will be multi-related function supported?
foreach ($article->related('article_tag:tag') as $tag) {
    ....
}
  1. 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 :-)

7 years ago

hrach
Member | 1818
+
0
-
  1. no
  2. already implemented, but you still didn't understand how you should use it, did you? It's possible even without SqlLiteral.
$db->select('AES_DECRYPT(secured_note, ?) AS secured_note', $aesPassword);

Last edited by hrach (2013-04-17 12:14)

7 years ago

nanuqcz
Member | 844
+
0
-

hrach: You are right, I didn't know that. Thanks :-)

7 years ago

Majkl578
Moderator | 1379
+
0
-

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…

7 years ago

bene
Member | 83
+
0
-

Union services names.
e.g.: @router VS @nette.mailer
All Nette services should have nette prefix.

For back compability may exists backCompabilityNetteServiceNames.neon contains:

services:
    router = @nette.router

7 years ago

enumag
Member | 2128
+
0
-

@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)

7 years ago

bene
Member | 83
+
0
-

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.

7 years ago

enumag
Member | 2128
+
0
-

@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)

6 years ago

enumag
Member | 2128
+
0
-

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?

6 years ago

Honza Marek
Member | 1674
+
0
-

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 ;)

6 years ago

Majkl578
Moderator | 1379
+
0
-

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.