Blady,
My use case is a online reporting-system, concerning what could be
considered a multi-part/multiple-report system.
Functionally, I have a collection of DIVs containing settable elements
(typically FORM-elements), which can be dragged into the report’s submission
area, which then reads the DIV’s elements and adds them to the FORM for
submission. (This allows e.g. multiple “observation” reports to be submitted,
EOD.) — The issue here comes into play when the user has a lot of
notations/comments to add, as this will make the ‘message’ text-area exceed the
500 characters limitation.
Much of the stuff could, eventually, be auto-generated, given an integrated
redesign of the current system; this would entail much, much more and would be
dealing with a very different set of operations (namely interfacing to various
scientific instruments, taking the readings/data, collating & storing it; the
reports in this scenario would then be essentially the metadata involved from
these processes with the occasional user-notes).
From: Blady via Gnoga-list<mailto:gnoga-list@lists.sourceforge.net>
Sent: Saturday, May 29, 2021 10:28
To: Gnoga support list<mailto:gnoga-list@lists.sourceforge.net>
Cc: Blady<mailto:blady-...@users.sf.net>
Subject: Re: [Gnoga-list] Improvements/bugfixes.
> Le 26 mai 2021 à 17:38, Joey Fish <tigerscla...@hotmail.com> a écrit :
>
> In handling form-data it was impossible to handle, via the HTML-Form POST
> method, arbitrary parameters because lack of a filter ensured that no
> parameters were processed. Following is the fix [in source-file
> gnoga-server-connection.adb] I’ve been using, though this results in some
> constraints for processing which prevent multi-user simultaneous access
> (because post parameters are handled individually, therefore simultaneous
> submissions cannot be handled).
<...>
> There is another limitation, one where any particular parameter cannot exceed
> 500 characters, this limit is set in the definition Gnoga_HTTP_Content, in
> the same source-file. Shown below.
> type Gnoga_HTTP_Content is new Content_Source with
> record
> Socket : Socket_Type := null;
> Connection_Type : Gnoga_Connection_Type := HTTP;
> Connection_Path : Ada.Strings.Unbounded.Unbounded_String;
> FS : Ada.Streams.Stream_IO.File_Type;
> Input_Overflow : String_Buffer;
> Buffer : String_Buffer;
> Finalized : Boolean := False;
> Text : aliased Strings_Edit.Streams.String_Stream (500);
> end record;
>
> I am working on a fix for this, the simplest would be to increase the
> discriminant to, say, 4096… but this merely moves the constraint to 4KB,
> instead of memory arbitrary [arguments may be made for both], so I will
> likely experiment on it to see if I can get a less-limited solution.
Hello Joey,
Well, few years ago, I came across these two issues when I had to dig in POST
mechanism.
I agree that this current way is not very convenient.
The value 500 should be a constant in gnoga-server-connection-common.ads.
Indeed, though GET and POST are supported, Gnoga is designed to play rather
with events.
What is your use case?
Regards, Pascal.
https://blady.pagesperso-orange.fr
_______________________________________________
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list
_______________________________________________
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list
