Jalopy only formats java sources! Not more! No xml files are touched!
Henner
> -Ursprüngliche Nachricht-
> Von: Shawn [mailto:[EMAIL PROTECTED]
> Gesendet: Dienstag, 17. August 2004 02:29
> An: Henner Kollmann; 'Dziugas Baltrunas'
> Cc: [EMAIL PROTECTED]
> Betreff: Re: AW: [dbforms] Sour
Sourceformatting is done by the maven:jalopy task and and prerun of forcing all files
to dos format.
We did this last year in october - and i think it would be good to do it again so that
all source files look equal.
Only problem for developers is that they must start with an clean checkout - me
Just tested this with bookstore/test/testBOOKSList.jsp:
[SELECT BOOK_ID, ISBN, AUTHOR_ID, TITLE FROM BOOK ORDER BY ISBN DESC]
So in bookstore example it works as you expected.
Also subforms are working:
[SELECT BOOK_ID, ISBN, AUTHOR_ID, TITLE F
Sourceformatting is done by the maven:jalopy task and and prerun of forcing all files
to dos format.
We did this last year in october - and i think it would be good to do it again so that
all source files look equal.
Only problem for developers is that they must start with an clean checkout - me
During my changes to use the jakarta-commons logging during the whole framework i had to change nearly each class.
Could you please describe what changes regarding this issue are going to
be made except this one:
http://cvs.sourceforge.net/viewcvs.py/jdbforms/dbforms/src/org/dbforms/servlets/Conf
Hi,
Sorry for the confusion. I was referring to the problem reported by
Dziugas Baltrunas on 2004-08-03.
Nevertheless here is an example,
database details:
create table ledger
(
ledg_code char(2) not null,
userid char(8) not null,
accid char(16) not null,
tt char(8) not null,
During my changes to use the jakarta-commons logging during the whole framework i had
to change nearly each class.
So before committing this changes i suggest to let the source formatter run over all
sources - so that they all look pretty well
after this.
This means for your development that you
Hi list,
During my changes to use the jakarta-commons logging during the whole framework i had
to change nearly each class.
So before committing this changes i suggest to let the source formatter run over all
sources - so that they all look pretty well
after this.
This means for your developme
Could write down an example?
Regards,
Henner
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Im
> Auftrag von jitu
> Gesendet: Montag, 16. August 2004 13:45
> An: [EMAIL PROTECTED]
> Betreff: [dbforms] orderBy in dbform tag bug
>
>
> I have encountered
I have encountered the same problem with sorting. The orderBy clause in
the dbForm tag is superseded by the "order by" clause that is worked
out dynamically at run time. This (overriding) uses the keys specified
in the dbconfig. The key fields are appended by doing a search from the
beginning of t
Yes, it is. DbForms always requires an sorted output. So always sorting after the key
fields is added.
Henner
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Im
> Auftrag von jitu
> Gesendet: Montag, 16. August 2004 11:18
> An: [EMAIL PROTECTED]
> Betre
Another observation:
the generated "select" statement is appending an "ORDER BY" clause which
has not been specified in the query. This seems to come from the table
definition of the "from" table. Is this a requirement of DbForms ?
regards,
Jitu
On Mon, 2004-08-16 at 08:10, jitu wrote:
> Hi,
>
The keyword "AS" is not required in SQL standard. Therefore some database do not like
it and generate error if it's inside the
query.
But you can change your table definition to include the "AS", e.g.:
Cheers,
Henner
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailt
Hi,
For a query using expression, the "select" statement does not include
the keyword "AS" when renaming output columns an this keyword is
required by postgresql. Is there a way of getting over this problem ?
Query:
The resulting select statement:
INFO org.dbf
14 matches
Mail list logo
