| Query Builder initial code contribution [message #23206] |
Thu, 16 November 2006 07:30  |
 Brian Payton
Messages: 154
Registered: July 2009 |
Senior Member |
|
|
DTP dev community:
I've checked in an initial code contribution for the DTP Query Builder
tool (aka "Visual Builder). It's in DTP CVS (/cvsroot/datatools) in the
org.eclipse.datatools.sqltools/prototype/plugins directory. There are
three plugins at this point:
-- org.eclipse.datatools.sqltools.parsers.sql2003
-- org.eclipse.datatools.sqltools.parsers.sql2003dml
-- org.eclipse.datatools.sqltools.sqleditorx
The plugins are not currently part of the DTP build process. You can
check them out from CVS into your workspace and include them in your
runtime environment if you want to play with them.
This is *very* early code. We're preparing the foundation for the query
builder, and our focus at this point of development is on the
interaction between the SQL parser and the SQL source editor. In fact
these initial plugins don't include any "builder" (visual) code at all.
Plugin sqleditorx (a temporary name) is based on the WTP SQL editor
plugin (org.eclipse.wst.rdb.sqleditor). We started with the WTP SQL
editor because it's simpler; we'll be porting the code over to the DTP
SQL editor base a little later. Note: I've temporarly disabled the
connection-related code in the editor, so you can write a query but not
run it yet.
So what we current have is a new version of the LPG-based parser and an
editor that is tightly tied to it. The LPG-based parser uses a new
technique for automatically generating the parser AST (Abstract Syntax
Tree) directly from the language grammar. The parser generator creates
Java classes that correspond directly to the grammar elements. (This
can significantly cut down the time needed to create a new parser.)
In the editor we are trying to achieve a user experience similar to the
JDT Java editor. That is, syntax errors are diagnosed and marked as
soon as you stop typing, and the error messages are pretty good. The
LPG parser is actually two parsers in one: one parser that generates an
AST, and another (the "diagnosing parser") that kicks in if the first
parser finds an syntx error, and tries to find and report as many errors
as possible. The outline view is generated directly from the generated
AST. In the next drop we should have full synchronization between the
source view and outline view (again, similar to the Java editor). That
is, if you click on a location in the source view, the corresponding
location in the outline view is selected, and similarly when you click
on a node in the outline view, the corresponding element in the source
view gets selected.
As I said, this is just a start. There are many more elements and
features to add, including:
-- semantic validation (do tables and columns exist?) using an
associated SQL model
-- intelligent content assist based on where you are in the statement
-- a parser manager for dynamically selecting a parser based on the
database connection type
-- code templates
and much more. And that's just for the source editor component. We
will be building the "visual" builder around this foundation. We have
some cool ideas on how to improve the interaction between the Assistant
view (the "visual builder") and the source view. Stay tuned.
Brian Payton
SQL and XML Query Tools Development
IBM Silicon Valley Laboratory
|
|
|
| Re: Query Builder initial code contribution [message #23234 is a reply to message #23206] |
Fri, 17 November 2006 02:06  |
Brian Payton
Messages: 154
Registered: July 2009 |
Senior Member |
|
|
I forgot to mention that this new editor associates itself with files
that have a .sql extension so if you do an "Open with >" action on a
xxx.sql file and select "Query Editor", you can launch the new editor
and play with it.
Brian Payton wrote:
> DTP dev community:
>
> I've checked in an initial code contribution for the DTP Query Builder
> tool (aka "Visual Builder). It's in DTP CVS (/cvsroot/datatools) in
> the org.eclipse.datatools.sqltools/prototype/plugins directory. There
> are three plugins at this point:
>
> -- org.eclipse.datatools.sqltools.parsers.sql2003
> -- org.eclipse.datatools.sqltools.parsers.sql2003dml
> -- org.eclipse.datatools.sqltools.sqleditorx
>
> The plugins are not currently part of the DTP build process. You can
> check them out from CVS into your workspace and include them in your
> runtime environment if you want to play with them.
>
> This is *very* early code. We're preparing the foundation for the
> query builder, and our focus at this point of development is on the
> interaction between the SQL parser and the SQL source editor. In fact
> these initial plugins don't include any "builder" (visual) code at all.
> Plugin sqleditorx (a temporary name) is based on the WTP SQL editor
> plugin (org.eclipse.wst.rdb.sqleditor). We started with the WTP SQL
> editor because it's simpler; we'll be porting the code over to the DTP
> SQL editor base a little later. Note: I've temporarly disabled the
> connection-related code in the editor, so you can write a query but
> not run it yet.
>
> So what we current have is a new version of the LPG-based parser and
> an editor that is tightly tied to it. The LPG-based parser uses a new
> technique for automatically generating the parser AST (Abstract Syntax
> Tree) directly from the language grammar. The parser generator
> creates Java classes that correspond directly to the grammar
> elements. (This can significantly cut down the time needed to create
> a new parser.)
>
> In the editor we are trying to achieve a user experience similar to
> the JDT Java editor. That is, syntax errors are diagnosed and marked
> as soon as you stop typing, and the error messages are pretty good.
> The LPG parser is actually two parsers in one: one parser that
> generates an AST, and another (the "diagnosing parser") that kicks in
> if the first parser finds an syntx error, and tries to find and report
> as many errors as possible. The outline view is generated directly
> from the generated AST. In the next drop we should have full
> synchronization between the source view and outline view (again,
> similar to the Java editor). That is, if you click on a location in
> the source view, the corresponding location in the outline view is
> selected, and similarly when you click on a node in the outline view,
> the corresponding element in the source view gets selected.
>
> As I said, this is just a start. There are many more elements and
> features to add, including:
> -- semantic validation (do tables and columns exist?) using an
> associated SQL model
> -- intelligent content assist based on where you are in the statement
> -- a parser manager for dynamically selecting a parser based on the
> database connection type
> -- code templates
> and much more. And that's just for the source editor component. We
> will be building the "visual" builder around this foundation. We have
> some cool ideas on how to improve the interaction between the
> Assistant view (the "visual builder") and the source view. Stay tuned.
>
> Brian Payton
> SQL and XML Query Tools Development
> IBM Silicon Valley Laboratory
|
|
|
| Re: Query Builder initial code contribution [message #583096 is a reply to message #23206] |
Fri, 17 November 2006 02:06 |
Brian Payton
Messages: 154
Registered: July 2009 |
Senior Member |
|
|
I forgot to mention that this new editor associates itself with files
that have a .sql extension so if you do an "Open with >" action on a
xxx.sql file and select "Query Editor", you can launch the new editor
and play with it.
Brian Payton wrote:
> DTP dev community:
>
> I've checked in an initial code contribution for the DTP Query Builder
> tool (aka "Visual Builder). It's in DTP CVS (/cvsroot/datatools) in
> the org.eclipse.datatools.sqltools/prototype/plugins directory. There
> are three plugins at this point:
>
> -- org.eclipse.datatools.sqltools.parsers.sql2003
> -- org.eclipse.datatools.sqltools.parsers.sql2003dml
> -- org.eclipse.datatools.sqltools.sqleditorx
>
> The plugins are not currently part of the DTP build process. You can
> check them out from CVS into your workspace and include them in your
> runtime environment if you want to play with them.
>
> This is *very* early code. We're preparing the foundation for the
> query builder, and our focus at this point of development is on the
> interaction between the SQL parser and the SQL source editor. In fact
> these initial plugins don't include any "builder" (visual) code at all.
> Plugin sqleditorx (a temporary name) is based on the WTP SQL editor
> plugin (org.eclipse.wst.rdb.sqleditor). We started with the WTP SQL
> editor because it's simpler; we'll be porting the code over to the DTP
> SQL editor base a little later. Note: I've temporarly disabled the
> connection-related code in the editor, so you can write a query but
> not run it yet.
>
> So what we current have is a new version of the LPG-based parser and
> an editor that is tightly tied to it. The LPG-based parser uses a new
> technique for automatically generating the parser AST (Abstract Syntax
> Tree) directly from the language grammar. The parser generator
> creates Java classes that correspond directly to the grammar
> elements. (This can significantly cut down the time needed to create
> a new parser.)
>
> In the editor we are trying to achieve a user experience similar to
> the JDT Java editor. That is, syntax errors are diagnosed and marked
> as soon as you stop typing, and the error messages are pretty good.
> The LPG parser is actually two parsers in one: one parser that
> generates an AST, and another (the "diagnosing parser") that kicks in
> if the first parser finds an syntx error, and tries to find and report
> as many errors as possible. The outline view is generated directly
> from the generated AST. In the next drop we should have full
> synchronization between the source view and outline view (again,
> similar to the Java editor). That is, if you click on a location in
> the source view, the corresponding location in the outline view is
> selected, and similarly when you click on a node in the outline view,
> the corresponding element in the source view gets selected.
>
> As I said, this is just a start. There are many more elements and
> features to add, including:
> -- semantic validation (do tables and columns exist?) using an
> associated SQL model
> -- intelligent content assist based on where you are in the statement
> -- a parser manager for dynamically selecting a parser based on the
> database connection type
> -- code templates
> and much more. And that's just for the source editor component. We
> will be building the "visual" builder around this foundation. We have
> some cool ideas on how to improve the interaction between the
> Assistant view (the "visual builder") and the source view. Stay tuned.
>
> Brian Payton
> SQL and XML Query Tools Development
> IBM Silicon Valley Laboratory
|
|
|
Powered by
FUDForum. Page generated in 0.01980 seconds
] 
Search
Help
Register
Login
Home
