× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Nathan

Ok, so jo actually means that a front-end programmer that uses node.js has
to
go to the back-end team every time he needs a comma changed in the mapping
of data from a table?

On Mon, Mar 26, 2018 at 8:09 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Henrik, I'll provide an inline response:

On Mon, Mar 26, 2018 at 11:42 AM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Nathan



well very clever RPG programmers has apparently decided to define all
their
columns as CHAR fields instead of VARCHAR in their legacy database and
that
will give technical inconsistency if connecters don’t follow the chosen
column design in the DB, so don’t shoot the messenger (the interface)
that
does comply to the DB design but shoot the DB designer.


I agree with using VARCHAR fields. But that doesn't address the issue of
legacy databases.

I don't suggest shooting the messenger (the interface). Just replace it
with granular web service APIs.



When that is said it is a bad idea to have trailing blanks in a browser
based UI simply because users has to delete characters the can’t see in
order to be able to insert characters in the string otherwise it should
trigger an error because they will try to pass a 40 char long string
into a
30 char long result field – what do you think happens in a SQL statement
if
you try that?



Yes, I'm aware that trailing blanks are a disservice to browsers.


This not either a question on open access from outside but rather
controlled access between native and PASE and if there wasn’t that you
can
forget of every thing that runs in PASE such as PHP, JAVA and all the
Open
Source modules available.


Okay. But if you provide granular Web service APIs, they can be invoked
from PASE, as well as from external clients.


And even if there was some form of trimming in the interface (you can
code
it in the SQL) you would still have the problem with legacy “numeric”
date
fields, booleans thet sometimes are 0/1 and other time Y/N but never
unsupported true/false etc. that is spread all over the IBM I databases.


Okay. I'd suggest correcting those problems in code that runs in the same
address space as the database, as opposed to "in an application".


And in basics there are no difference in repacking/mapping raw DB table
data to either JSON, XML, X.12 etc. – as well as you have to do mapping
of
the receivables or does SQL or DB supports raw FORMS encoded data or URL
gets escape sequenses - I hardly believe that - so you have to have a
layer
where you do it.


You can obviously perform just about any type of logic in client
applications. But I still see advantages to running data mapping code in
the same address space as the DBMS.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.