Scott Eade wrote:
>
> So, Login.java retrieves the data to populate a Subject
> object and places this in the Velocity context thus:
>
> Subject subject = (Subject) SubjectPeer.doSelect(criteria).elementAt(0);
> context.put("entry", subject);
>
> > >
> > > 4. A screen template that includes:
> > >
>
> In my screen template I need to map from $entry to
> intake thus:
>
> #set ( $group = $intake.Subject.mapTo($entry) )
>
> This maps the values from $entry to intake with the key
> set to the value returned by $entry.getQueryKey() (at
> least this is what it appears to be doing). $entry and the
> subject group in intake both include a SubjectId, as
> does the form (I have included these myself). It is also
> included in the form a second time as "subject" (the key
> of the group) by virtue of $intake.declareGroups() at
> the bottom of the form.
>
> In theory I can use the Default key thus:
>
> #set ( $group = $intake.Subject.Default )
>
> I would do this when there was no entry to begin with
> and I just wanted to validate a form against an intake group.
> Is this correct?
>
That sounds like you understand it.
> Incidentally, how does the mapToObject attribute of <group>
> in the intake xml file relate to this? The documentation seems
> to say that if I omit this attribute then intake can retrieve the
> values directly. This sounds like a desirable thing to be able
> to control, but I don't quite get it.
>
If the Subject group did not map to any object so that mapToObject="",
then you would supply a key or use the Default. In such a case you
would not use mapTo or setProperties, etc. The fields would not be
prepopulated the first time the form is shown. When you set a
mapToObject on a group it is expected that you will be supplying objects
of that type to back the group, so that the form can be prepopulated
with data and the object can be updated with the form data.
> > > 5. An action SaveForm.java (a variation of SQL.java)
> > > that includes (excuse my use of the error log, I don't
> > > seem to be able to get debug logging to work):
>
> <off-topic>
> Any idea why:
>
> org.apache.turbine.util.Log.debug("text to go to the debug log");
>
> doesn't work out of the box? Do I have to change something in
> TR.properties to get the debug messages to be produced?
> </off-topic>
>
The logging properties have undergone changes recently, but the general
idea is that in the TR.props logging properties there are some
properties that end in (or contain) "level" which is set to ERROR or
INFO or DEBUG, etc. Make sure the appropriate one is set to DEBUG.
> > I am a bit confused by your use of the Default_Key. It is also showing
> > up in your html shown at the end, but I see no mention of it in your
> > sample template above. I would use
> >
> > group = intake.get("Subject", entry.getQueryKey());
> >
> > where entry would be the same object (or representing the same object,
> > as in having the same PrimaryKey) You appear to be using a new Subject
> > even to represent an object that is already saved in the database. I
> > don't recommend this, but it could be made to work.
> >
> > The DEFAULT_KEY is meant to be used in cases where the fields do not map
> > to any object and instead of making up a key, a default one is
> > provided. There is nothing special about it as a key.
>
> That makes sense. I now have:
>
> Group group = intake.get("Subject", data.getParameters().getString("subject"));
>
> I am assuming that the "subject" (really the group key) field is added
> to the form to allow for this. As I am now using the correct key to
> retrieve the intake group, isValidAll() on the group now works.
The hidden fields added at the end of the form are added for intake's
internal use. They allow intake to construct the keys it needs to look
for as opposed to searching all the input and parsing the keys to
extract information. It is more efficient. Though there is no reason
you can not make use of the data.
> I can also go:
>
> Subject entry = new Subject();
> group.setProperties(entry);
>
> to give me a Subject object that I can then update in the database:
>
> entry.setModified(true);
> entry.setNew(false);
> entry.save();
>
> > > 6. In case it is relevant, here is the generated html
>
> The bottom of the generated form is now:
>
> <input type="hidden" name="subject2s" value="2"/>
> <input type="submit" name="eventSubmit_doInsert" value="Insert"/>
> <input type="submit" name="eventSubmit_doUpdate" value="Update"/>
> <input type="submit" name="eventSubmit_doDelete" value="Delete"/>
> </div>
> <input type="hidden" name="intake-grp" value="subject"></input>
> <input type="hidden" name="subject" value="2"></input>
> </form>
>
> I include this to show the subject2s field (which is the
> SubjectId I included in the intake xml file and the form
> as well as the subject field which is the one generated by
> $intake.declareGroups() .
>
> My last outstanding problem is that when a validation
> error is picked up by intake and the form is redisplayed,
> $entry is no longer in the context and thus the form is
> displayed with no fields filled in. I'm sure I had this
> working at one point, but I can't seem to repeat it.
> Can you spot my hopefully obvious mistake?
>
I do not understand why $entry would be in the context the first time
Login.vm is displayed but not the next time. Login.class's methods will
be invoked in the exact same way every time. But you are instantiating
a new Subject each time, I am not sure how it would contain the data you
want. But the form fields should be showing the entered form text the
second time anyway so what is in $entry should not matter, except that
it have the same QueryKey.
john mcnally
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
