Feature #789

Catalog Search : use GET instead of POST (like in v2)

Added by Blatti Yves about 5 years ago. Updated about 4 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

100%

Category:CATALOG
Target version:4.3.0
Sponsor: Ergonomic impact:
Functional impact:

Description

Is there a reason easySDI Catalog Search Form use POST form instead of GET ?
V2 Catalog was in GET.

That allows us to:
- share results page by URL
- create search results page dynamically (pre-setting some fields)
Plus it avoid "re-POST" confirmations in browsers.

Any reason not using GET method ?


Related issues

Related to easySDI - Feature #798: Add a catalog option : scroll to results yes/no Closed 08/13/2014

History

#1 Updated by Blatti Yves about 5 years ago

I have tested it, the modifications are very light:
- URI parameters have to be set in hidden fields
- form method has to changed to GET

Note: in any cases, it's only the initial search ("button click") that is made using POST method, when you browse next pages of catalog, GET is already used.

#2 Updated by Blatti Yves about 5 years ago

The only downside I see is GET URL size limitation.
RFC 2616 doesn't limit the length of URI:

[...]
The HTTP protocol does not place any a priori limit on the length of a URI.
[...]

So limitation comes from browsers and servers:
Like always, Internet Explorer is the worst! (UP to version 10): 2083 Bytes. (http://support.microsoft.com/kb/208427)

For information, others software limitations are:
Browsers:
>100 KB for Firefox, Chrome and Safari
>200 KB for Opera
Servers:
128 KB for Apache (Default is 8KB)
16 MB for IIS (Default is 16KB)

If look a the IE restriction of 2083B , that allows us to send a request with some text fields, booleans, etc + dozens of values of multi-lists (small when with db ids, or big like 36B guid, for organisms in example)

I made a test on our search form, just under IE limit, with:
- 2 text fields (with 20+ chars, one is CSW)
- 1 bool
- 20 elements of mlist (small ids = 4 chars)
- 20 elements of mlist (guids = 36 chars)

So what do we do? Do we plan using gigantic search forms?

#3 Updated by Blatti Yves about 5 years ago

One more remark: if we choose to keep POST method, we'll have to adapt the pagination system to also use POST, or create some more logic... (searchfields in serverside session , etc..)

#4 Updated by Blatti Yves about 5 years ago

If we choose the GET method (which is my favorite, despites of the downside of my dear fried IE ), here is the tested code:

components\com_easysdi_catalog\views\catalog\tmpl\default.php:L46

<form class="form-horizontal form-validate sdi-catalog-fe-search" action="<?php echo JRoute::_('index.php?option=com_easysdi_catalog' ); ?>#results" method="get" id="searchform" name="searchform" enctype="multipart/form-data">
    <?php 
    $tmpl = JFactory::getApplication()->input->get('tmpl', null, 'string');
    if(isset($tmpl)):?>
    <input type="hidden" name="tmpl" id="tmpl" value="<?php echo $tmpl ; ?>"/>
    <?php endif; ?>
    <input type="hidden" name="view" id="view" value="catalog"/>
    <input type="hidden" name="search" id="search" value="true"/>
    <input type="hidden" name="id" id="id" value="<?php echo $this->item->id; ?>"/>
    <input type="hidden" name="preview" id="preview" value="<?php echo $this->preview ; ?>"/>
    <div class="catalog front-end-edit">

#5 Updated by Blatti Yves about 5 years ago

  • Status changed from New to Request For Comments

#6 Updated by Blatti Yves about 5 years ago

  • Related to Feature #798: Add a catalog option : scroll to results yes/no added

#7 Updated by Blatti Yves about 5 years ago

  • Status changed from Request For Comments to Request For Votes

#8 Updated by Blatti Yves about 5 years ago

Technical Committee stated that changing from POST to GET can easily be done.

But limitation from GET URL size must be kept in mind, and the problem might emerge for certain users.

Plan is:

  • Implement GET instead of POST now
  • If needed in the future:
    • Fully implement POST:
      • in search form
      • in pagination links
      • make it optional in backend (GET or POST)

Attention: linked to #798 because changing to GET will break HTML anchor auto scroll system.

#9 Updated by Mérour Xavier almost 5 years ago

+1 for me

#11 Updated by Magoni Bruno almost 5 years ago

+1

#12 Updated by Magoni Bruno almost 5 years ago

  • Status changed from Request For Votes to Accepted

#13 Updated by Blatti Yves almost 5 years ago

  • Status changed from Accepted to Affected
  • Assignee set to Blatti Yves

#14 Updated by Magoni Bruno almost 5 years ago

  • Target version changed from Unplanned to 158

#15 Updated by Blatti Yves almost 5 years ago

  • Status changed from Affected to Resolved
  • % Done changed from 0 to 100

Merged in 4.3.x
#798 is still to be done

#16 Updated by Magoni Bruno over 4 years ago

  • Target version changed from 158 to 4.3.0

#17 Updated by Villemagne Jérôme over 4 years ago

  • Status changed from Resolved to Closed

#18 Updated by Van Hoecke Hélène about 4 years ago

  • Assignee deleted (Blatti Yves)

Also available in: Atom PDF