On Sun, 2004-11-07 at 20:00 +0100, Enrique Ariz=C3=83=C2=B3n wrote:
> def respond(self, trans):
> # checkings and more checkings.
> # resultMapping "interprets" the results. For
> example, a client sends
> # formIdx=3D3242 from an HTML ddbb view form.
> resultMapping maps 'formIdx' to 'formFK_client_idx',
> # 'formFK_document_idx', ... deppending on the
> contextInPlace =3D
> resultMapping =3D
> for oldFieldName in resultMapping:
> contextInPlace['ServletAwareOfResult'] +
> self._request.extraURLPath() )
> The idea is that visual code generation is not aware
> of the context and meanings of the generated forms,
> and just when the client user fills and send a valid
> value it is translated in something meaningfull.
> My doubt come next. To map field names I'm accessing
> the "private" member _fields and so my code depends on
> HTTPRequest implementation that can't be considered
> good practice. =C2=BF Is there any other way to do in an
> standard or correct way ?
You are correct in that you'd be depending on the=20
HTTPRequest implementation. If you want to avoid this,=20
why not write your mapping like so:
req =3D self.request()
for oldFieldName in resultMapping:
val =3D req.field(oldFieldName)
> If the answer is NO, who I am to email to convince
> for the inclussion of an HTTPRequest method like:
> def mapFieldNames(self, dicFieldNamesMapping)
You'd need to enter a bug on webware's sourceforge project page,=20
and attach a patch. However, my gut feeling is that a "mapFieldNames"
method is too specialized and doesn't really belong in Webware. Nor
is it necessary, since it can be written using the existing public API
as I have shown.