[fpc-devel] fcl-web webdata ExtJS "total" field question
Hi, 1. Should not the JSON replies have a "total" returned always like the XML replies? Right now "total" is not returned if the "start"/"limit" is not passed to the formatter. 2. How can I provide the correct "total" for the response if I only loaded exactly the records requested by ExtJS into the dataset but not the whole table? Ex: Have a table with 1000 records, I'm on page 2 of the grid that has a page limit of 50 records. Of the total 1000 records, only about one third should be visible for the person currently requesting data. Therefore, I run a SQL statement to get those next 50 records from the 333 potential ones for this person, and that will be displayed in the grid, and only those 50. This way, only I can tell in the response the correct "total", which is 333 in this case. 50 was passed to the formatter/adapter. Thanks, AB ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fcl-web webdata example(s) on Windows has some problems
..snip...
We can add the "rows" for convenience, but nevertheless the error handler
must also handle the 'response' case.
Michael.
Hi Michael,
I've created an updated ExtJS error handler for the demo programs that
handle all these response messages from FCL-web without the need to
change the internals and play with the "rows". We just need to update
the *.js files for the demos.
=CODE START
// Listen to errors.
data.addListener('exception', function(proxy, type, action, options,
res) {
if (type === 'remote') {
Ext.Msg.show({
title: 'REMOTE EXCEPTION',
msg: res.message,
icon: Ext.MessageBox.ERROR,
buttons: Ext.Msg.OK
});
}else{//type === 'response'
if (res.responseText !== undefined){//there is a responseText so
we can process
var succ = undefined;
var mess = "";
try {
//mark start
var response = Ext.util.JSON.decode(res.responseText);
succ = response.success;
mess = response.message;
//mark end
if ((succ !== undefined)&&(!succ)){//success == false
Ext.Msg.show({
title: 'REMOTE EXCEPTION/ERROR',
msg: mess,
icon: Ext.MessageBox.ERROR,
buttons: Ext.Msg.OK
});
};
}//try
catch (err) {
Ext.MessageBox.alert('ERROR', 'Could not decode server
response: ' + res.responseText);
};//catch
};
};//else
});//addListener
==CODE END
For XML communication we need to change between the "mark start / mark
end" to
//mark start
var response = document.createElement('div');
response.innerHTML = res.responseText;
s = Ext.DomQuery.selectValue('success', response);
switch (s.toLowerCase()) {
case "true" : succ = true;
case "false": succ = false;
};//switch
mess = Ext.DomQuery.selectValue('message', response);
//mark end
AB
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] NoGlobals branch
Jonas Maebe schrieb: In contrast to the preceding OO approach, a bunch of ordinary procedures still waits for becoming methods, with faster access to frequently used class members. Should I try to convert the procedures to methods now, or should I wait until everything else has settled down? Please polish and finish one self-contained part, get that reviewed and merged into trunk, Then I'd say it's the right time for review just now :-) DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fcl-web webdata example(s) on Windows has some problems
...snip... I don't 100% agree: the exception() handler must also be able to handle 'response'. If there is a server crash or so (which will result in a 500 error code) , it must also be able to handle that. We can add the "rows" for convenience, but nevertheless the error handler must also handle the 'response' case. Michael. just found this: It seems that someone had the same problem with ExtJS and even created a bug report there: http://www.sencha.com/forum/showthread.php?91903-OPEN-826-DataProxy-Exception-JsonReader-Possible-Inconsistency He did the same adding the "rows" trick to solve it. The problem is, that when the 'response' case comes, the object is not processed (because the exception is thrown from within ExtJS before the response is really processed) so we cannot access the response properties to display it to the client. Might be only a problem with JSON reader, I am not sure. AB ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] NoGlobals branch
On 18 Aug 2010, at 12:34, Hans-Peter Diettrich wrote: In contrast to the preceding OO approach, a bunch of ordinary procedures still waits for becoming methods, with faster access to frequently used class members. Should I try to convert the procedures to methods now, or should I wait until everything else has settled down? Please polish and finish one self-contained part, get that reviewed and merged into trunk, and then continue (or use different branches, although then you will have to merge things and resolve conflicts). In particular, do not concurrently change different things in one branch (mixing fixes and/or new features in your refactoring, or mixing different kinds of refactoring that can also be done independently), because that makes it harder to review the code and less likely to get anything merged. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc patch - big or small
In our previous episode, Graeme Geldenhuys said: > > Michael, there is only one issue I have with fpdoc at the moment. It is > regarding Marco's recent change regarding resolving links. See the > following Mantis report for details. > http://bugs.freepascal.org/view.php?id=17146 > > If I use the code as Marco committed it, then fpGUI's class documentation > works fine. All links are active and pointing to the correct places. But > then RTL & FCL's IPF output links are broken. Swap them around like I did > in the IPF patch (dglobals.pp line 990-995), then RTL and FCL docs links > work, but fpGUI's links are broken. :-( If I understand it well, the code currently tries to first lookup #rtl.xxx and then #rtl.currentmodule.xxx The problem was before a relative path could not be an unit name, or be relative to an unit name (classes.tstringlist) So the order should only matter for identifiers that duplicate as unitnames. (and these should then be made with absolute paths, since both solution then are not safe) Anyway, I don't see anything here that could lead to corrupt links. p.s. My agenda for fpdoc in the coming week: - Make sure that inheritance data is available over package bounderies. This will make inheritance trees work over package bounderies (and does the prepatory work for interface trees too) - reduce the noise (warnings). I suspect several of these errors are redundant because they are the result of multiple different attempts at resolving. This will probably mean a few more service routines that only issue a warning if nothing can be found using multiple means. But that is only a hunch, I still have to read up on this part of fpdoc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fcl-web webdata example(s) on Windows has some problems
On Wed, 18 Aug 2010, ABorka wrote: ...snip... ExtJS however, will only have 'remote' type if the server response is proper for it (having a root /which is "rows"/ in our case), all other cases instead of 'remote' it has the type 'response', regardless of our "success" property being true or false. Unfortunately, the ExtJS documentation is rather terse where this is concerned. So, if "rows" is not supplied, type='response' and the 'success' property must simply be checked ? Or do you suggest adding "rows" to the error response ? I'm not sure if this is also the case if you are using a DirectStore ? The docs for Ext.DataProxy -> events -> exception says it in more detail. " Fires if an exception occurs in the Proxy during a remote request. This event is relayed through a corresponding Ext.data.Store.exception, so any Store instance may observe this event. ... # type : String The value of this parameter will be either 'response' or 'remote'. * 'response' : An invalid response from the server was returned: either 404, 500 or the response meta-data does not match that defined in the DataReader (e.g.: root, idProperty, successProperty). * 'remote' : A valid response was returned from the server having successProperty === false. This response might contain an error-message sent from the server. For example, the user may have failed authentication/authorization or a database validation error occurred. " We are always getting type='response' now (due to "response meta-data does not match that defined in the DataReader") with the "rows" not being there when an exception/error happens server side, so no error message we pass is processed in our ExtJS. I do not know about DirectStore, I just started with ExtJS/JSON with playing with the demo apps from fcl-web a few days ago :) Does it hurt anything if we just append a "rows":"" to our error/exception replies? I did that with the 1st demo app and it works so far, displays the errors from the server side now (like "DB field X cannot be null", "Cannot connect to DB server", "Invalid DB user", etc.). I don't 100% agree: the exception() handler must also be able to handle 'response'. If there is a server crash or so (which will result in a 500 error code) , it must also be able to handle that. We can add the "rows" for convenience, but nevertheless the error handler must also handle the 'response' case. Michael. AB ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] NoGlobals branch
The removal of global variables is almost finished now. I know that the code currently doesn't look nice, and that performance can be improved, but these are minor details compared to the attempts to not break the compiler itself. In the last round a GlobalModule has been added, that plays the role of a not yet existing current_module at compiler initialization. Since the remaining global variables currently are scattered across many units, they could be moved all into the GlobalModule - any opinions? For performance reasons it were nice to have unit-level properties with variable refences for the getters, instead of subroutines - any reasons why this is not allowed right now? What should be done in the next step? In contrast to the preceding OO approach, a bunch of ordinary procedures still waits for becoming methods, with faster access to frequently used class members. Should I try to convert the procedures to methods now, or should I wait until everything else has settled down? Another task were the separation of the implementation parse and code generation, from interface parsing. This separation would allow for multiple worker threads for e.g. code generation. Any suggestions? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fcl-web webdata example(s) on Windows has some problems
...snip... > ExtJS however, will only have 'remote' type if the server response is proper for it (having a root /which is "rows"/ in our case), all other cases instead of 'remote' it has the type 'response', regardless of our "success" property being true or false. > >Unfortunately, the ExtJS documentation is rather terse where this is concerned. >So, if "rows" is not supplied, type='response' and the 'success' property must simply be checked ? Or do you suggest adding "rows" to the error response ? >I'm not sure if this is also the case if you are using a DirectStore ? The docs for Ext.DataProxy -> events -> exception says it in more detail. " Fires if an exception occurs in the Proxy during a remote request. This event is relayed through a corresponding Ext.data.Store.exception, so any Store instance may observe this event. ... # type : String The value of this parameter will be either 'response' or 'remote'. * 'response' : An invalid response from the server was returned: either 404, 500 or the response meta-data does not match that defined in the DataReader (e.g.: root, idProperty, successProperty). * 'remote' : A valid response was returned from the server having successProperty === false. This response might contain an error-message sent from the server. For example, the user may have failed authentication/authorization or a database validation error occurred. " We are always getting type='response' now (due to "response meta-data does not match that defined in the DataReader") with the "rows" not being there when an exception/error happens server side, so no error message we pass is processed in our ExtJS. I do not know about DirectStore, I just started with ExtJS/JSON with playing with the demo apps from fcl-web a few days ago :) Does it hurt anything if we just append a "rows":"" to our error/exception replies? I did that with the 1st demo app and it works so far, displays the errors from the server side now (like "DB field X cannot be null", "Cannot connect to DB server", "Invalid DB user", etc.). AB ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FPC 2.4.2 and revision merging
Hello, I have no idea what is the status on the fpc 2.4.2 release, so I though I might ask for a revision to be merged to it =) This basically fixes TrueType font drawing. The previous rendering had wrongly spaced characters, which is unworkable, so I don't see how this patch could make things worse. The same revision also fixes linking truetype in Mac OS X, which previously wasn't implemented. http://bugs.freepascal.org/view.php?id=17156 http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=15827 thanks, -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-pascal] fcl-web webdata example(s) on Windows has some problems
On Tue, 17 Aug 2010, ABorka wrote:
did some more testing:
ROUND 4
1. minor note: We should not forget that field names are case sensitive in
ExtJS, so any database field names need to be entered exactly:
ex:
fields: ["id","login","name","email", "lastlogin"]
is not the same as
fields: ["ID","LOGIN","NAME","EMAIL", "LASTLOGIN"]
or
{header: 'ID', dataIndex: "id", sortable: true, hidden: true},
is not the same as
{header: 'ID', dataIndex: "ID", sortable: true, hidden: true},
In the demo projects a DBF table is used with all capital letter field names.
When I tried to use MySQL, it took me some time to realize this problem.
Having zero errors displayed for this didn't help either :)
Yes.
The case sensitivity of Javascript (and hence JSON) has given me grey
hairs prematurely :-)
2. major: It seems that the error/exception handling does not have the proper
server responses for ExtJS (when read/insert/update/delete happens on the
data), because with any exceptions there is nothing displayed but the empty
grid with "no data to display" note.
Apparently, we need to append a '"rows" : ""' to our responses in order for
ExtJS to properly accept our reply with the error message (being "rows" is
our root element and ExtJS requires this):
ex: instead of
{ "success" : false, "message" : "Blahblah exception occured CGI side" }
it should be
'{ "success" : false, "message" : "Blahblah exception occured CGI side",
"rows" : ""}
(not sure how using XML instead of JSON needs this done differently)
This needs to be done within our reply generation internally (fcl-web) when
there is an error/exception or the message will never be displayed client
side. Explanation:
In our *.js we have
data.addListener('exception', function(proxy, type, action, options, res) {
if (type === 'remote') {
Ext.Msg.show({
title: 'REMOTE EXCEPTION',
msg: res.message,
icon: Ext.MessageBox.ERROR,
buttons: Ext.Msg.OK
});
}
});
This is ExtJS boilerplate code, with nothing FPC specific about it.
ExtJS however, will only have 'remote' type if the server response is proper
for it (having a root /which is "rows"/ in our case), all other cases instead
of 'remote' it has the type 'response', regardless of our "success" property
being true or false.
Unfortunately, the ExtJS documentation is rather terse where this is
concerned.
So, if "rows" is not supplied, type='response' and the 'success' property must
simply be checked ? Or do you suggest adding "rows" to the error response ?
I'm not sure if this is also the case if you are using a DirectStore ?
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
