Quantcast

Let's create one more plugin together

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Let's create one more plugin together

Fedor Belov
Plugin creation is very difficult task - we don't have so much free time to complete it fast. I suggest you to create one more plugin together.

Here is the idea:

What I don't like in Grails? I'm talking about development process

1. When you changes something in devmode you don't know was it reloaded or not. You press F5, then F5 again and so on
2. Logging. When the request is processed I need logs only for this request
3. Exceptions. If there were an exception it will be cool to get simple access to it
4. SQL requests / NoSQL operations / HTTP requests/responses - I wanna get simple access to it
5. Total processing stacktrace with spend time.

How can we solve it?

We can create plugin that will add bar to the page in devmode. This bar may have different tabs. For example:
1. Reloaded files. Updatable by websockets
2. Logs for current request with filter ability
3. Exceptions
4. SQL requests
5. HTTP requests / responses (it will be usefull to debug REST API like SOLR)
6. and so on

So you will have super simple access to important information. It will save your time a lot.
I think there are a lot of work to be done. But it can be splitted by developers.

Hope somebody like the idea. When I'll finish my current plugin I will start described one. Still suggesting you to implement it together
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Let's create one more plugin together

Marc Palmer Local
This was something I started working on, and platform-core was part of making it happen - the nav Api would allow extensibility of the bar, events would be used to hook into things for alerts and notifications

Before platform core I started a plugin that shows at runtime in the browser when reloading occurs, and let's you inspect the request history, drilling down into request attributes, model variables for each response and sessions. It had a pre-platform core way to extend the buttons in the bar etc.

Also the grails rocks plugin includes a bunch of runtime info useful in dev, i.e. What plugins you have, which licenses they have, links to their docs, and whether there are new releases.

Also platform core was designed to allow runtime configuration of your app. The config Api name spacing an declarative DSL is all about this. There is even a "secret" PluginConfig.groovy that is loaded and merged into config so you can build a dev time web UI for configuring plugins - it has the type of the setting and a fully qualified name that can be used to resolve a ui description string - think about a dynamic ui in the browser for reviewing and editing your plugin configs.
 
Obviously I ran out of steam on all this and some of the features would require changes to grails core. For example getting notification of exceptions and which request they related to, and ideally having some simple push mechanism to the browser ui from grails core - without requiring a specific container. The challenge is making all this work with all the web configurations grails can be used in now and in the future. I don't know if any of the code still works / with grails 2.

I didn't see much support for this kind of interface in the past -  I shared the debug ui plugin with other grails developers. Perhaps it will be taken up by the community. I hope so but it's a big job and really needs assistance from the core devs.
--
Marc Palmer


> On 13 Jun 2013, at 08:33, Fedor Belov <[hidden email]> wrote:
>
> Plugin creation is very difficult task - we don't have so much free time to
> complete it fast. I suggest you to create one more plugin together.
>
> Here is the idea:
>
> What I don't like in Grails? I'm talking about development process
>
> 1. When you changes something in devmode you don't know was it reloaded or
> not. You press F5, then F5 again and so on
> 2. Logging. When the request is processed I need logs only for this request
> 3. Exceptions. If there were an exception it will be cool to get simple
> access to it
> 4. SQL requests / NoSQL operations / HTTP requests/responses - I wanna get
> simple access to it
> 5. Total processing stacktrace with spend time.
>
> How can we solve it?
>
> We can create plugin that will add bar to the page in devmode. This bar may
> have different tabs. For example:
> 1. Reloaded files. Updatable by websockets
> 2. Logs for current request with filter ability
> 3. Exceptions
> 4. SQL requests
> 5. HTTP requests / responses (it will be usefull to debug REST API like
> SOLR)
> 6. and so on
>
> So you will have super simple access to important information. It will save
> your time a lot.
> I think there are a lot of work to be done. But it can be splitted by
> developers.
>
> Hope somebody like the idea. When I'll finish my current plugin I will start
> described one. Still suggesting you to implement it together
>
>
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Let-s-create-one-more-plugin-together-tp4645756.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Let's create one more plugin together

Fedor Belov
I think it's possible to change grails-core if it makes sense. Of Course
we should try to solve it without changing grails-core.

There are about 800+ plugins. How many do I know? 5? 10? Only big ones
like resources, platform-core, *-security and so on. I think there are
already exists plugins that partially solves described problems. But I
don't know them. May be because I'm lazy - I don't wanna search/add 5
more plugins to solve my problem. I wanna one plugin that will solve all
my problems.

So we can get code/ideas from many similar plugins, create core and and
merge them into single plugin. Like you did in platform-core - you have
solved 3-5 problems and merged them into single plugin. You didn't
create platfrom-events, platfrom-config and so on.

13.06.2013 12:32, Marc Palmer Local [via Grails] пишет:

> This was something I started working on, and platform-core was part of
> making it happen - the nav Api would allow extensibility of the bar,
> events would be used to hook into things for alerts and notifications
>
> Before platform core I started a plugin that shows at runtime in the
> browser when reloading occurs, and let's you inspect the request
> history, drilling down into request attributes, model variables for
> each response and sessions. It had a pre-platform core way to extend
> the buttons in the bar etc.
>
> Also the grails rocks plugin includes a bunch of runtime info useful
> in dev, i.e. What plugins you have, which licenses they have, links to
> their docs, and whether there are new releases.
>
> Also platform core was designed to allow runtime configuration of your
> app. The config Api name spacing an declarative DSL is all about this.
> There is even a "secret" PluginConfig.groovy that is loaded and merged
> into config so you can build a dev time web UI for configuring plugins
> - it has the type of the setting and a fully qualified name that can
> be used to resolve a ui description string - think about a dynamic ui
> in the browser for reviewing and editing your plugin configs.
>
> Obviously I ran out of steam on all this and some of the features
> would require changes to grails core. For example getting notification
> of exceptions and which request they related to, and ideally having
> some simple push mechanism to the browser ui from grails core -
> without requiring a specific container. The challenge is making all
> this work with all the web configurations grails can be used in now
> and in the future. I don't know if any of the code still works / with
> grails 2.
>
> I didn't see much support for this kind of interface in the past - I
> shared the debug ui plugin with other grails developers. Perhaps it
> will be taken up by the community. I hope so but it's a big job and
> really needs assistance from the core devs.
> --
> Marc Palmer
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Let's create one more plugin together

Graeme Rocher-2
In reply to this post by Fedor Belov
Would be a great plugin, something like that is definitely on the TODO list, just when i'm not sure.. maybe i'll find time after 2.3


On Thu, Jun 13, 2013 at 9:33 AM, Fedor Belov <[hidden email]> wrote:
Plugin creation is very difficult task - we don't have so much free time to
complete it fast. I suggest you to create one more plugin together.

Here is the idea:

What I don't like in Grails? I'm talking about development process

1. When you changes something in devmode you don't know was it reloaded or
not. You press F5, then F5 again and so on
2. Logging. When the request is processed I need logs only for this request
3. Exceptions. If there were an exception it will be cool to get simple
access to it
4. SQL requests / NoSQL operations / HTTP requests/responses - I wanna get
simple access to it
5. Total processing stacktrace with spend time.

How can we solve it?

We can create plugin that will add bar to the page in devmode. This bar may
have different tabs. For example:
1. Reloaded files. Updatable by websockets
2. Logs for current request with filter ability
3. Exceptions
4. SQL requests
5. HTTP requests / responses (it will be usefull to debug REST API like
SOLR)
6. and so on

So you will have super simple access to important information. It will save
your time a lot.
I think there are a lot of work to be done. But it can be splitted by
developers.

Hope somebody like the idea. When I'll finish my current plugin I will start
described one. Still suggesting you to implement it together



--
View this message in context: http://grails.1312388.n4.nabble.com/Let-s-create-one-more-plugin-together-tp4645756.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email





--
Graeme Rocher
Grails Project Lead
SpringSource
Loading...