SoftTree Technologies SoftTree Technologies
Technical Support Forums
RegisterSearchFAQMemberlistUsergroupsLog in
[ES] - snippet enhancements I

 
Reply to topic    SoftTree Technologies Forum Index » SQL Assistant View previous topic
View next topic
[ES] - snippet enhancements I
Author Message
gemisigo



Joined: 11 Mar 2010
Posts: 2102

Post [ES] - snippet enhancements I Reply with quote
This one was born during the discussion of this topic.

1. Currently, snippets can have their "end results" cast either into the code editor or displayed in the results pane. Having a third option/result target, a popup, populated with the "end results", that would allow choosing from the items and then adding that to the contents of the code editor (the way the popups usually work), that could drastically boost the snippet feature's (already tremendous) versatility.

2. Currently, the $CURRENT...$ macro can pick one of the following: current word/qualified name/selection/line or any words/item backward from the cursors current position (up to 9 positions back). It could have a new option or the Parameter ones could be extended similarly as they are now with Escape quotes/Names only/Do not replace/etc., so that they not only could fetch the words but could also interpret them the way $OBJECT...$ macro does, for example, $CURRENT(param1, dont_replace, ins_object)$ and $CURRENT(param1, dont_replace, ins_colum)$ to get the column name that resides at location param1 and the table name that contains that column. The basics required for that (fetching the column name and figuring out from the query which table it belongs to) are already there somewhere in the code because that's what Ctrl+clicking a column does. The difference is that now you "Ctrl+click" using a cursor position-aware macro and you only have to pass the data that was used in the column data retrieval query to the user, you don't even have to execute the query itself, the user can decide what to do with that data. Just like when those are fetched by the $OBJECT...$ macro.

Combining #1 and #2 hitesh could have implemented the requested column value intelligence with a pure-snippet-based solution. And yes, as usual, I definitely do not have the slightest idea how difficult it would be to implement #1 and #2 ;)
Tue Sep 21, 2021 5:09 am View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 7843

Post Reply with quote
1. If I may summarize your proposal, you are asking for custom popup windows / lists with custom contents populated from database using $$..$$ macro.

2. $CURRENT...$$ macro can also return selected text or the entire line. Selecting relevant part of text may spare the need for intelligent parsing.


Both 1 and 2 can be actually implemented using the existing plugin interface and Plugin Development IDE that allows extending the existing SQL Assistant features. Snippets have their limits, beyond snippets there are SQL Assistant plugins for SQL Assistant and targeted environments that support more sophisticated methods, including custom menus, graphical panels, etc... For example a plugin can be created to show prompts with dynamically populated lists from database and copy the selected value into the editor. Everything for creating plugins is preinstalled. Here is a quote from the user's guide for the plugins "Plugins can be used to extend SQL Assistant functionality and by proxy to extend functionality of the target database development environment. They can be used to add new features to SQL Assistant menus, windows, and panes. In most cases you would likely want to develop some new graphical forms, to prompt users to enter some input parameters or choose some options."

Beyond that plugin interface using built-in scripting engine, there is another extensibility interface for developing plugins in .NET, basically in Visual Studio and adding them to SQL Assistant.

Having said that, I admit that plugins are not for everyone. There is some learning barrier, and it might be challenging for those who don't have general application programming experience.
Wed Sep 22, 2021 12:25 am View user's profile Send private message
gemisigo



Joined: 11 Mar 2010
Posts: 2102

Post Reply with quote
The summary is not quite on the mark.

#1.
While it is true that I'd like to populate the list with custom content from the database using the $$..$$macro, but I don't think that would require a custom popup, the built-in ones could work just as well. They are already doing that. Many (most?) of the popups get their content from queries that can be checked/altered/slaughtered in Options / DB Options / DB Queries.

I thought getting a result from a $$..$$ macro (which has a working, implemented solution) and then "putting" that content to a popup instead of the code editor or the result pane would be simple. A clear goal, straightforward process. Like eg. the result of the Schemas DB Query is processed and pushed into a popup that appears after typing DROP SCHEMA (that is, another part of the process that already works). I guess altering this to be able to work this way takes comparably less effort than creating a whole new infrastructure basically from the ground up for doing the same thing in a custom, user-built component. Not to mention that whoever trying to do that would have to reinvent the wheel, recreate lukewarm water, and probably step into the same traps and implement the same bugs you've already ironed out years ago.

This is what I meant when I talked about in this post here. You'd "only" have to redirect the data to a different target. It's not even a new target, as the popups are already a feature and there are already result of $$..$$-like queries being thrown in their direction.

#2.
"Selecting relevant part" won't work without intelligent parsing. Fetching the text from the entire line would probably not be enough anyway, the column might be on the same line but the table most likely will not be. Selecting parts of the code that contains everything an intelligent parsing would require to determine without doubt the objects needed for the query might be still too complicated for a semi-intelligent (i. e. dumb as a brick) parser. Furthermore, the text retrieved by the $CURRENT...$ macro could only be parsed using SQL as language because that's the only thing you can generally use in a snippet. And we all know, that one is not the sharpest spoon in the drawer when it comes to writing any kind of text parser. This distills down to the same result as #1. If it cannot use the intelligent parsing already present in SA (see Ctrl+clicking a column in a statement), it would have to reinvent the wheel, recreate... etc.

Imho, creating a plugin for an entirely new feature is justified. Writing one to merge two existing features would also make a sound decision. But having to completely rebuild both the features from the scratch (because that's what this would essentially be) just to be able to merge them would be too much pain for a too-small gain.

Hmm, ever thought about adding, I don't know, let's say Python to the $$...$$ macro? Python can do miracles with both strings and datasets. Nothing would be impossible anymore...
Wed Sep 29, 2021 9:32 am View user's profile Send private message
Display posts from previous:    
Reply to topic    SoftTree Technologies Forum Index » SQL Assistant All times are GMT - 4 Hours
Page 1 of 1

 
Jump to: 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

 

Powered by phpBB © 2001, 2005 phpBB Group
Design by Freestyle XL / Flowers Online.