Select to view content in your preferred language

Enhanced-Search-Widget-for-FlexViewer Part III

201604
776
04-30-2013 03:58 PM
RobertScheitlin__GISP
MVP Emeritus
All,

   Here is a new thread to post questions and discuss the Enhanched Search Widget. The old thread was getting too long.
Tags (2)
776 Replies
RobertScheitlin__GISP
MVP Emeritus
Brandon,

   I do not have a hard number to give you. The big thing to remember is that the Viewer is not ArcMap on the Web. The Viewer only have a portion of the memory that is allocated to the browser application (as it is a browser plug in) vs ArcMap is a application and has access to larger amounts of memory. So you might (or might not) be able to do 50,000 points, but 50,000 polygons is not feasible as the eSearch results are added to the map as a FeatureLayer (thus the plugin actually allocated memory for the geometry for each result, which is drawn client side). There is a reason that esri sets the default of a map service to 1000 features.
0 Kudos
RobertScheitlin__GISP
MVP Emeritus
Derek,

   Hmm... When did this start happening? You either have something really screwed up in your eSearchWidget.xml or you have found a bug no one else has seen. When you say the drop down is empty, is your drop down width extremely small?
0 Kudos
DerekHunter1
Deactivated User
I didnt think there were major changes to the config structure, so I pretty much used my 3.2 version esearch xml config. I attached the config.

Derek,

   Hmm... When did this start happening? You either have something really screwed up in your eSearchWidget.xml or you have found a bug no one else has seen. When you say the drop down is empty, is your drop down width extremely small?
0 Kudos
RobertScheitlin__GISP
MVP Emeritus
Derek,

   Which version of the widget are you using? Are you specifying the width and height attributes in the widget tag of the main config.xml for the eSearchWidget?
0 Kudos
DerekHunter1
Deactivated User
3.5 is the version.   Here is my eSearchWidget portion of the main config.

<widget label="Search" right="15" top="209" preload="open"
                icon="assets/images/i_search.png"
                config="widgets/eSearch/eSearchWidget_Whiting.xml"
                url="widgets/eSearch/eSearchWidget.swf"/>

I apologize as I may not be effectively explaining my issue.  The issue I am seeing isn't related to the position of the widget, but rather the size of the drop-down now allowing the layers to be seen.  Its confusing as I didn't change the mxml at all, just the eSearchWidget.xml file which I attached in my previous response.

Derek,

   Which version of the widget are you using? Are you specifying the width and height attributes in the widget tag of the main config.xml for the eSearchWidget?
0 Kudos
RobertScheitlin__GISP
MVP Emeritus
Derek,

  Ahh... That was what I was looking for. Just add a width attribute to the eSearch Widget in the main config.xml
This is a new Bug in the 3.5.3 version. It will be addressed in 3.5.4.

<widget label="Search" right="15" top="209" preload="open"
                icon="assets/images/i_search.png" width="400"
                config="widgets/eSearch/eSearchWidget_Whiting.xml"
                url="widgets/eSearch/eSearchWidget.swf"/>
0 Kudos
DerekHunter1
Deactivated User
Thanks so much!

Derek,

  Ahh... That was what I was looking for. Just add a width attribute to the eSearch Widget in the main config.xml
This is a new Bug in the 3.5.3 version. It will be addressed in 3.5.4.

<widget label="Search" right="15" top="209" preload="open"
                icon="assets/images/i_search.png" width="400"
                config="widgets/eSearch/eSearchWidget_Whiting.xml"
                url="widgets/eSearch/eSearchWidget.swf"/>
0 Kudos
DongxingMa
Emerging Contributor
Dongxing,

This is strange as I get error 400 when using the standard esri search widget when using a joined layer that has a subtype. Actually That is the test case I shared with esri when reporting this bug.

Also strange that you say  esris search widget does handle subtype fine as long as there is no join as well.

Whether you leave the Subtype field out of your eSearchWidget.xml field list or not does not matter as esri adds the subtype field automatically in the API when a query is done on a layer that has a subtype defined in its REST end point. The only way to get past that is to hide the Subtype field in the MXD before you publish the map service. Once you hide the SubType field in the MXD and republish the service (with the Join), then version 3.5.3 works just fine as well as older versions of the eSearch.

Why?.. In 3.5.3 Subtypes works and joined tables has worked way back since the 2.x version of the widget.



Hi Robert,

This is really interesting, we have some different findings and test results:

1>I have been using ESRI's regular search widget, it does handle joined table/fields well, and at the same time, I mean while the joined table exists, it can display and even search by subtype field, won't give error or stop search process, the only issue for me is: it doesn't display subtype's description, it just directly returns the code number. (seems different with your finding!)

2>for your eSearch widget 3.5.3, I found when no joined table exists, it handles subtype field well, returns the description; but if a joined table and a subtype field both exist (change field names in the configuration accordingly, of course), then the esearch process crushes, gives the "400" error. (are you seeing different result when both subtype field and joined table existing in the search layer?)

3>I thought eSearch 3.5.3 cannot handle joined table even subtype field turned off in the mxd, so I said that I may have to go back to use 3.5 version. This is a mistake. I found the subtype field wasn't turned off yesterday when testing.

Now I am sure as long as subtype field turned off, eSearch 3.5.3 handles joined table/fields well, so I will use the latest version eSearch.

4>I still hope you make a version that can have subtype field and joined table/fields co-existing in the search layer, won't give error, can finish search, just treat subtype field as a regular field, directly return the code number. This way, we can use a domain table join to the subtype field, and search by subtype field but return the joined domain table's description field. This is what I have done using the OTB search widget.

Hope I have made my points clearer now. Please advise me if you see any better solution.

Thanks!
Dongxing
0 Kudos
RobertScheitlin__GISP
MVP Emeritus
Dongxing,

   This might be a difference in ArcGIS Server 10.2 that I am using and 10.1 that you are using. Because using 10.2 and the OTB search 3.5 w/Join and w/Subtype the search fails.

Because of my finding with the 10.2 of server and the fact that I don't have control of the API adding the subtype field if it is present in the Rest Endpoint. I can not make a version that will work as you are wanting.
0 Kudos
JayHalligan
Occasional Contributor
I have been using the esearch widget for some time now, but I have just run across a problem and I am not sure what is causing the issue.  I have published an X,Y event layer to our server on Amazon EC2 which is dynamically reading a SQL table that is updated nightly.  But....When searching the event layer

a)uniquevalsfromfield causes all of the search values to not work
b)without the expression uniquevalsfromfield, the widget is only returning the first value it finds

Any ideas?  The widget works fine on our internal server(and internal SQL) but not when I transferred the widget.  It also works fine on the server when the database was copied to the amazon.


I figured out that I lost my "Object ID" on the event layer when pointing the source information to a new database. This was causing only the first feature found to be returned.  Great Widget so thanks again.
0 Kudos