This Cousin covers the three main mailing lists for the GNU Enterprise project, plus the #gnuenterprise IRC channel. Kernel Cousins GNUe is now group-authored: if you'd like to join the team, let us know.
Referring back to
does
anybody knows about the inclussion of features implemented in our patch into
gnue?
James Thompson (jamest) said i'm still
working on it
. He had been hoping to get to
over the holidays
but was now hoping to start this week.
Later, Marcos asked did you hacked anything in the
way of <form style="dialog" />
, as discussed in
a fair bit of the work is done
-
i just need to make some more adjustsment to the
UI
. Marcos asked for any hints as to how this would work -
I need to either reproduce it or backport it when is
done.
James said there would be radical technical changes -
I wouldn't reimplement - if you can give me the time
<dialog> was to be able to replace your genericBox - i planed on that being
a dynamically created <dialog>
.
Derek Neighbors (revDeke) said no offense if you
would use official cvs you would save a LOT of time
. James pointed out
that papo were still using their own CVS as I'm still
trying to merge their changes up stream so they can migrate up
. Derek
said that was my point - it takes time away from
adding new features to try to sync with them - and then they out of sync
again
. He isnt overly
concerned from a gnue standpoint, just would like to help papo out by giving a
consistent tree
- but the gnue team cant
constantly spend time trying to resync
. Marcos said that, for some time,
we (almost) stopped to add features to our cvs ('cept for
bug fixes)
.
Marcos added I guess we'll have our cvs anyways, as we
have functionality that will never get into gnue. unless there were other ways to
introduce them, like delegation in the db arch
, as discussed in
so what you are saying is you want a
fork
. Marcos disagreed - it's the last thing we
want.
Derek said well if you have your own cvs
you have a fork
- it might be a minor fork but
a fork none the less
. He felt that GNUe had bent
over backwards to apply patches that you would stop using your own cvs so we wouldnt
have such headaches
. James said we're not fast
enough for their business needs - that's all - i mean it's been weeks/months(?)
Derek said well its a two edge sword - you have dialogs
almost done and styxman will spend two weeks implementing or back port - so whom is
slowing whom down
? Applying patches generated from papo's CVS back into the
main GNUe CVS was time-consuming, and was only really worth it if papo were intending
to use GNUe's CVS in the future.
Federico Heinz (perlhead) said We most definitely
*don't* want to fork. We're doing our best to work with what we currently
have.
Derek emphasised that he was not opposed to forking -
there are two types of forks - a pure fork... we make
foo, you want to go right i want to go left and we fork - and - a mild fork, we
make foo, you want to go right, we want to go right, you want to dress in red, we
want to dress in blue - in a mild fork it makes sense to 'share' as much as
possible - as things are going same direction.
He
would rather see papo just use gnue and drop own
cvs
but understands business requirements and
timelines
. However, just like in a data
conversion if you continue entering data in old system you will never cut over to
the new one
.
He felt that this dialog sample proves as well -
there is functionality that might come into our cvs you want - and its murder for
you to back port it.
However, if dialogs
will take you 2 weeks to do - and its in our system - and if it takes two weeks
to get cvs head to give you proper functionality
, then there was no issue
as the work could be done in GNUe's CVS directly and
you are in sync - /me isnt saying thats the case - but you have to look at such trade
offs
. Federico said that getting the papo CVS in sync with GNUe's would
take much longer than two weeks - Marcos had played
catch up for quite a while in nov/dec, and he never got anywhere near the head
branch.
Derek felt that the only way to re-sync was
to check out our cvs - then add the functionality to
it thats missing and submit as patches - one patch per functionality - not a giant
patch - a. that will minimize amount of wait time you would incur from us - b. that
ensures our cvs does what you need - in the mean time stop adding stuff to your
cvs
. Federico said that the Problem is, as I
understand it, that if we do that, our stuff STOPS WORKING. And we must have a
widely deployable version in two months. Debugged and tested.
Derek
said well then i would say it behooves you to do
ASAP - unless you forever want a fork - as if you deploy you will NEVER get back
to our cvs - as you will never be able to 'stop' adding features to sync up.
Again im not saying you must do this, or even necessarily that you should do
this - that is up to you - just be forewarned we wont take patches created from a
cvs other than our own
. Marcos did not think there was actually much
difference in functionality. Federico agreed - there's
not actually that much more that we need... just now, a few UI things, and
then we can rest.
Derek warned that the forthcoming changes to the GNUe
Forms Definition format (.gfd) in version 0.5.0 would make papo's CVS
incompatiable going forward without MAJOR work on
your tree
.
Marcos noted that there were some changes in papo's CVS that
won't get into gnue ever. and we know that.
Derek said for somethings like that if one off deals
you could treat like
patches to the Linux kernel,
where its a 'mini fork' for specific
functionality
. Federico agreed, but said that the bigger issue was
We have stuff we need, and that GNUe wants but
does not yet have in HEAD.
Marcos said that, as papo had several
devlopers, they would still want to have a CVS even if just for version
control on their own patches.
Federico fully appreciated Derek's point about ideally merging CVS before
papo did a wider release, but it's a financing
thing
- if we get a solution that *works*
by march, we get the funding we need to continue work, and that work goes
according to *our* schedule.
Derek could relate to that, but warned
if you dont make papo tree like 0.5.0 it will be
an utter bitch for you to back port any new functionality we put in
.
He appreciated that papo have always been more
than eager to share their improvements, i want to make it abundantly clear
the gripe is not that they want to fork gnue and not give back - its more
that applying patches is utter hell, because they are created off a cvs tree
other than our own and in masse
. Federico said that the funding
situation means that we *will* do some shit
twice, which we could have gotten right the first time. But if doing so will
cost us our release date, we won't even get to the point where we can get it
right once.
Derek agreed - the question
is does it outweigh what it will cost you to merge the other stuff over
later? Once all of the papo patches from November had been applied,
our cvs head after those patches might not be all
that radiacally different feature wise - anywho its up to you guys to decide
whats best for you
. Federico said that papo's clients were not that
used to software development cycles - they were
Sustainable development organizations,
mostly.
- They have great trust in us,
and we do all in our power to keep that trust.
Further to
been
thinking about the SKU thing.. I can imagine 3 ways to organize a
Stock Keeping Unit (SKU) - 1)
Simple serialized number which is N digits long. 2) A number with N
segments one or more of which are a serialized number and one or more are
derived from predefined lookup tables and 3) a segmented number completely
derived from lookup tables
. Segments could either have
a predefined padded length
or be
delimited with or without a contraint on
their length/scope.
If there
was a way to configure how a SKU were established, then you could use that
information to create your forms to manipulate them based on that
configuration.
This meta-data could be queried to build the
form according to the data extrapolated.
Descriptions would be labels, if the segment was a lookup a dropdown could
be created, etc..
Derek Neighbors (derek) said the way i planned
on doing it was drop downs and triggers - you selected the 'categories' or
such that generate the numbers
. He added i
really think making a dynamic form is a bad solution - at least in the gnue
world. Maybe for gnue proper - but getting sku numbers that complex in gnue-sb
i think is over kill.
The main requirement for his clients was to be
able to generate new SKU for new items using pre-existing categories from
drop-down lists, but also use SKUs that did not fit the standard pattern -
i.e. the sku# is a free form field - but you can
use the categories to generate a number
. His users would typically have
three levels of category. Mike said that, with too many segments, this
could would create very large numbers and very
large numbers are hard to manage outside of the computer.
However, as if I were a consultant this could be a
bonus to be able to adapt to a running system rather than expect a migration if
things didnt fit.
His numbers are completely
derived from lookup tables and are in 5 segments/categories
.
Marcos Dione (StyXman) asked how should
I use the .04to0.5 conversor?
Dmitry Sorokin (ra3vat) said
run it with your form as param - old form
will be saved with <name>-PRE050 name
. The conversion
routine, which was designed to convert GNUe Form Definitions (.gfd)
from the format used in version 0.4.x and earlier to the new format
that split the logic and the display, was not completely automatic,
but in most cases mine worked
.
Marcos said ok, I'll finish the file by
hand
. Later, Jason Cater explained that the syntax for the
conversion script was
.gfd04to05.py
<source.gfd> [<destination.gfd>]
- if you specify
two names on the command line, then the second one is the output name
and the first one is left unchanged - if you only specify one form,
then the original is renamed and the new one is created in its
place
Earlier, Marcos reported various errors trying to run a converted
form, most of which seemed to be caused by the convertor putting
all my buttons in the logic part
.
This was a very simple form, just with a few buttons. He
wondered if this was the problem - can a
form have no logic?
Jason asked
do you have a <button> as a child of
a <block> ??
. Marcos said this was true of
all the buttons
. Jason said that
the conversion script was not accounting for
buttons in blocks
. Marcos confessed we
have more complicated things like that. boxes inside boxes inside blocks
and so on. would that be 'wrong'?
Jason said
well, the converter won't support it - nor
will
the CVS head version of GNUe Forms -
I'm not sure what it will do
.
Dmitry and Marcos concluded that the new format .gfds always had to
have a <logic> section - at a minimum, this had to contain a
<block> tag to specify which datasource to use. The conversion
script would fail with very simple forms that had no datasource, but
converted forms could then be made to work by manually adding a dummy
datasource - Marcos noted that tmpDataSource
is valid
.
Marcos asked about containers for widgets. Jason said
we haven't implemented containers yet - in
the old version or the new - with the exception of a
<page>
. Marcos said I sent a
patch for that one a looong time ago and it almos got in, but it was
disabled for 0.4.0 release, AFAIK
. Jason explained
it broke a lot of existing forms - when
applying I thought it was backward compatable - but I haven't had time
to correct it
. He thought we are
leaning to not having a dual function <box> tag, but an actual
container tag of sorts - but I'm not 100% sure what we want to do there
yet
.
Dmitry asked where should trigger be tied
to field tag in logic or entry tag in layout? what's the difference if
both ways are possible?
Jason said there's
not a 1:1 relationship between a field (logic) and an entry (layout)...
there's a 1:many. most of the time you'd probably want to do a <field>
trigger
. He confirmed that on-change triggers should exist for
field tags, as for entry tags.
Marcos Dione (StyXman) asked Dmitry Sorokin (ra3vat) whether he knew what
was the supposed semantics for the different masks (display, input, format).
Marcos needed them to show just a few decimal but
keeping all the decimals internally.
James Thompson (jamest) was
afraid that's up in the air right now IIRC
.
Marcos said he just want to know if I should
implement displaymask or format mask. and what will be the use in thew
future.
James thought there is
already work done on format masks, it's already in the code base but not
in use IIRC
. Marcos raised another question:
ok, let's do the question in a better way (I
hope): what are display, input and format mask for? Especially, the
difference between display and format? Input seems rather clear.
James noted that his answer came only from memory:
fields can display differently when you edit
them vs when you're not in them. The best place to see this is in a date
field, as IIRC it's the furthest along. When you enter the field,
2003/01/06 may be displayed for editing. When you exit it may flip to
read "Monday, Jan. 6th 2003". I _think_ display is non editing and format
is editing, but again, I'm not sure.
Marcos replied -
it sounds to me, but I may be wrong, that display
is for showing (Mon, Jan 6th 2003), input for input (2003/01/06), and format
for internal representation (20030106)
and James, on the whole, agreed:
that could very well be. I think that 2 of the 3
are in use and the 3rd one is pending proper setup of the format definition.
The best source of info on this would be jason.
Mike Vincent
(Vee2d2) noted that there's a bit of information
in the forms dev guide (.5) pg 24.. but the only thing documented is
datetime.
Later, Marcos caught Jason Cater (jcater) and he answered immediately:
masks don't work. That's part of
0.5
. However, Marcos was also interested what
are they exactly for. I mean, de dev-guide talks about display and input masks,
what is format for?
Jason was still wondering if GNUe needed the
"format" mask. Input mask --> when field is in input
mode, the mask used to validated/let the user enter the value, display mask
--> how the field is displayed when user is not editing it, format mask
--> (if there's a need) how the field is actually stored in the
database
.
Dmitry Sorokin (ra3vat) enquired is it possible
to do something like colspan in reports?
(in general, in native xml
report format). James Thompson (jamest) offered using
simple tabulation, just put in empty column defs
<out:col/>
. Dmitry was trying to do
simple text output that fit with 80 chars screen to be send by
email. It'd be great to split one output db row on two rows in report ans span
wide cells if needed
. James thought that
with a little effort you might be able to get a trigger to
do it, but the trigger support in reports is functional bu not complete. I would
think some type of post-change trigger on a field that split the data and stored
in 2 non-bound fields would do it
. Dmitry asked
how to reach different report objects from report
trigger
? James said that they should be able
to be referenced by name
. There were no examples
on this as of time of writing, because it seems that no one had used triggers in
reports. James expected to write an example sometime later the same week.report.fieldName
James Thompson (jamest) spoke about a practical use of GNUe Reports
from his own organisation - i took
some sample code jason wrote for Oracle Reports/zope/php and reworked
using GNUe Reports/Zope(with ZShellScripts).
It takes an RTF template of an invoice, merges it against data in the
rdbms, and pumps out a pdf file via a web site so customers can lookup
past invoices. what's cool is if the people this is for use it for
initialy printing their snail mail invoices then they will be the exact
same as the pdf
.
Dan Bethe (dtm) reported a possible lead for someone looking
to move to Bayonne on a totally shoestring budget.
probably can't even afford new hardware, still using ISA phone cards
;)
. Bayonne now had a demo mode that could run on an ordinary
sound card so you can test your bayonne
apps
. Daniel Baumann (chillywilly) suggested
do you call up custumers and yell,
"show me the money!!!" - cause that would be the cool way to collect
on accounts payable ;)
. Dmitry Sorokin (ra3vat) asked
what will be lost in that "testing" mode -
/me owns a coulpe of sound cards and a heap of old soldering parts
too
. Dan said it can't make
phone calls obviously - you can just listen, and the software will
function. as it can be very expensive or difficult to test on live
equipment like a T1
. Dmitry felt that might not necessarily
be the case - we have to find one 2400
modem to make a phone call
. Dan confirmed that, for a basic
but useful Bayonne installation, your 2400 bps
modem can be your call center
- as long as it could
do voice ;)
. John Lenton (Chipaca)
asked what exactly can bayonne do? is it
just a call center thing? or is it anything else?
Dan
pointed to the
website, suggesting go ahead and take a
look - it's the best IVR on the planet! Think of it as the apache of
telephony - takes virtually any type of telephony device and turns it
into a call center, an IVR, voicemail server, etc
. John asked
whether IVR is an interactive voice
racoon?
After a series of various racoon jokes, Dan explained
IVR == interactive voice response - i.e. a menu
with prompts and often voicemail - "thank you for calling XXX. press
1 for sales, 2 for collections, and 3 to troutslap chilly"
.
Daniel Baumann (chillywilly) urged everyone to
pick 3! pick 3!
.
Reinhard Müller (reinhard) announced that the
new Appserver API is fully implemented -
we now need - * somebody who makes the RPC around this work - * a
dbdriver for forms that uses the new api
. Actually,
it means that most of the api calls in
usual cases have a result that is very close to what it should be
;-) - but it should be enough to build upon
.
Anthony Lenton (aa_) queried an entry in the XML DTD for GNUe Forms, which
did not seem to work when he tried it. He was using the latest CVS version.
Jason Cater (jcater) said in cvs, the gfd format is
changing somewhat - I guess the DTD needs to be regenerated
. He
explained we have moved the layout management to use a
separate namespace - this is so we can migrate to supporting multiple layout
mechanisms w/in the same form i.e., absolute positioning, grid layout, gridbag,
etc. I think the "creating your first form" chapter in that pdf shows this -
but because the layout stuff (x,y,width, height) is now in a separate
namespace a separate dtd would be needed
.
Anthony read the Developers' Guide, with details of the new format, and
typed in the sample, which he could not get to work.
It exits with ' Entry references non-existent
field 'zipcode' I set up the db as is suggested. The field really honestly
does exist
. Dmitry Sorokin (ra3vat) suggested
start with more simple example that does not
require db
. Anthony tried to remove all
entries from the same example. It exited with 'There are no navigable widgets
in this form. Unable to display.
Later, Derek Neighbors (revDeke)
confirmed this error message was as expected - a form had to have at least
one entry field, but not necessarily tied to a database. John Lenton (Chipaca)
confirmed that Anthony's connections.conf settings were correct,
and with --debug-level it says it's reading the right
connections.conf
.
Dmitry suggested if desingner is not broken
you can easily build a simple form with wizard - and wizard will allow you
explore your conncetions.conf file (choose datasource or db) and db tables
when choosing particular columns
. Anthony reported that the
Designer seemed to work fine, but the Run-Form menu option from within
Designer bombed out. Dmitry suggested saving the form, and running it
from GNUe Forms directly. Derek said have you
confirmed that forms works at all? If not, please run samples/intro/intro.gfd
first to confirm that it functions properly - if it does then lets get a
database form working
. Anthony confirmed that
ok! intro.gfd works fine - i'll take a look at
how that works and move on from there
. Derek explained that
there is a HUGE jump from non datasource to
datasource forms - and fortunately or unfortunately a lot can go wrong with
datasource forms that have NOTHING to do with gnue - i.e. database or database
driver misconfiguration - so we like to use a dataless form to get a 'quick'
view of whether forms itself is working
.