Suggesting configuration parameters in section "Nette"
Opened this issue · 20 comments
It would be nice, if plugin can suggest me configuration parameters in Nette section (session, database, latte, etc...)
It is already there, perhaps new keywords shall be added as well? Or I guess we shall add these into a separate nette plugin, because this is not raw neon
Similar to #9
I guess we shall have some external definition of available keywords, in several contexts. Is there something like Neon Schema? (http://json-schema.org/examples.html, http://en.wikipedia.org/wiki/XML_Schema_(W3C))
@hosiplan, you've got many configurator extensions which would be nice to have autocompletion as well. Any ideas how to list available keywords for each extension?
Actually I don't want to postpone this, because I love autocompletion (im too laz to typ ful words)
@dg have you got something already? Can we discuss it to check whether it would be easy to add IDE support for it?
@juzna you may add autocompletion for nette section (it wouldn't change that much), but general support would be harder and should wait for the validators.
There is a difference between DI service schema and config.neon schema. Because there are 4 steps of processing:
- convert NEON to intermediate format (because we have support for different formats)
- merge multiple files
- expand parameters (in 2.1, so it is impossible to have validation scheme in 2.0)
- validating (in 2.1)
So I have plan to add some validation scheme, but it will be validator for partially processed file, not for source neon file.
@dg the point here is to have autocompletion based on the defined validation schema, not validation itself (well, maybe) :)
I understand, I'm just saying that there will be no validation schema for neon in Nette.
Imo we should split neon & neon config support. Neon config should have another extension. Neon support should be clear with php class autocompletion etc. Neon config should have some validation, autocompletion, section hinting, etc.
Yep we may split the plugin eventually, but not now. It's not about having hundreds of plugins, but about getting some work done ;)
I'll try to prepare some kind of very simple neon schema which will be used for autocompletion and validation in IDE.
well, I wasn't talking about splitting the plugin, but splitting the available features for autocompletion. The first step is the detection, what do you want to validate/autocomplete.
possibilites:
- by extension - sth like
*.neon
and*.neonc
- by heuristic, comment, annotation?
By config*.neon ?
(BTW, we need to version Neon syntax, because it is developed)
What about this kind of annotations?
/** Edit: DEPRECATED: do not read this anymore!!! Proceed to the other example. */
class NetteExtension extends Nette\Config\CompilerExtension
{
/** @configDefaults("nette") */
public $defaults = array(
'session' => array(
'debugger' => FALSE,
'iAmUsingBadHost' => NULL,
'autoStart' => 'smart', // true|false|smart
'expiration' => NULL,
),
);
/** @configDefaults("nette.database.*") */
public $databaseDefaults = array(
'dsn' => NULL,
'user' => NULL,
'password' => NULL,
'options' => NULL,
'debugger' => TRUE,
'explain' => TRUE,
'reflection' => 'Nette\Database\Reflection\DiscoveredReflection',
);
Or an unobstrusive way, similar to Factory Methods which are built in PhpStorm:
<?php
// .phpstorm.meta.php
namespace NEON_META { // we want to avoid the pollution
$CONFIG_KEYS = [
'dibi' => [ 'host' => '', 'dbname' => '', 'user' => '', 'password' => '' ], // unobstrusive static definition
'nette' => \Nette\Config\Extensions\NetteExtension::$defaults, // no problem the property is actually not static
];
I've got proof of concept of the unobtrusive way ready (8875871) and it's pretty pleasant to use. I think it's better than annotations (the first way).
Great, now the application can generate it using some kind of extension :)
I created a sample metadata file from which I believe it would be possible to provide very good autocompletion. Please
- have a look at it
- try to add more metadata for your compiler extensions, so that we can see whether it's understandable
- provide any comments
Thanks!