Just wondering if anyone had time to look this up. I can't decide if I did anything wrong. Thanks.
On Tue, Nov 20, 2012 at 12:51 PM, Muhammad Gelbana <m.gelb...@gmail.com>wrote: > Ok so I ripped much of my original page's and kept the essentials only. > Thank you for your time. > > > On Tue, Nov 20, 2012 at 11:34 AM, Ivan Khalopik <ikhalo...@gmail.com>wrote: > >> It doesn't matter how these controls are rendered by normal request or by >> zone update. They all will be rendered with fixed names and with errors >> connected to them. >> Just some rules to make this all work: >> - place FixedControlName mixin on form or zone. >> - define t:id attribute explicitly for all form controls. It is needed to >> prevent name conflicts between requests. >> - in zone update handler return whole zone component instead of just its >> body. It will prevent processing of actions saved by actually invisible >> components >> >> E.g. you have form without these controls: >> >> <form ...> >> <input name="brief"/> >> >> </form> >> >> Then you do something and some other controls are shown by ajax: >> >> <form ...> >> <input name="brief"/> >> <input name="full_3eaBasdfGjh"/> <!-- required, hash added to name because >> of ajax request --> >> >> </form> >> >> Then you submit form, validation fails and error are saved for ontrol with >> name 'full_3eaBasdfGjh', then page is refreshed: >> >> <form ...> >> <input name="brief"/> >> <input name="full"/> <!-- required, hash is not added as it is normal >> request --> >> >> </form> >> >> As name is 'full' now and error is saved for 'full_3eaBasdfGjh' you have >> no >> errors on the page. Then you make the same error and submit form. Now this >> error will be saved for control with name 'full' and after page is >> refreshed it will be shown with error. >> >> When you use FixedControlName mixin you will always have 'full' name, and >> everything will work as expected. >> >> The other part of this issue is how to show invisible components(inside >> block) when validation fails. Usually it depends on some other submitted >> control value. If not then you can add hidden control to save this state. >> Maybe you can provide some code snippet for better help. >> >> On Mon, Nov 19, 2012 at 11:14 PM, Muhammad Gelbana <m.gelb...@gmail.com >> >wrote: >> >> > I will recklessly assume I have fully comprehended your mixin. I >> couldn't >> > get it to work thought since my zones are initially empty (filled later >> > through ajax or a t:delegate if the page is refreshed) and your mixin >> > operates on components being rendered. Also I have my fields in >> > *t:block* elements >> > and they aren't rendered initially by nature of course. >> > >> > I'm fairly new to these methods so I'm stuck here and I have no ideas to >> > workaround this. Don't you think this deserves a JIRA as at least an >> > improvement if not a bug ? Or may be any other ideas ? >> > >> > And thanks a million for your help :) >> > >> > On Mon, Nov 19, 2012 at 5:44 PM, Ivan Khalopik <ikhalo...@gmail.com> >> > wrote: >> > >> > > All this because of changed form controls names after ajax update >> (some >> > > hash added to the end). After form submission this controls saves >> their >> > > state for changed names (with hash) and then are rendered to client >> with >> > > normal names(without hash). As they searches for erros by name they >> can >> > not >> > > find any. >> > > I have my solution for such sittuations, to fix control names, make >> them >> > > static. I've described this here: >> > > >> > > >> > >> http://mutabra.blogspot.com/2012/09/tapestry-fixed-control-name-fixin.html >> > > >> > > On Mon, Nov 19, 2012 at 6:37 PM, Muhammad Gelbana < >> m.gelb...@gmail.com >> > > >wrote: >> > > >> > > > I use <t:error> for each field. >> > > > >> > > > Here is some more enlightening investigation results, based on the >> fact >> > > > that the form's fields are changed using ajax, once the fields are >> > > updated, >> > > > the fields errors are shown only after the first submission and the >> > same >> > > > happens every time the form field's are changed. So it has >> something to >> > > do >> > > > with binding the fields with the "validation tracker on the client >> > side". >> > > > >> > > > In another words, on the second submission, the page is fully >> loaded so >> > > the >> > > > "client side validation tracker" is setup right and bound to the >> > fields. >> > > > But when I update the form's fields using ajax, it's broken. I have >> a >> > > > feeling this could be wrong but its my very best guess so far. >> > > > >> > > > On Mon, Nov 19, 2012 at 5:33 PM, Ivan Khalopik <ikhalo...@gmail.com >> > >> > > > wrote: >> > > > >> > > > > Do you use <t:errors> component to show errors for whole form or >> just >> > > use >> > > > > separate <t:error> components to show errors for particular field? >> > > > > >> > > > > On Mon, Nov 19, 2012 at 6:28 PM, Muhammad Gelbana < >> > m.gelb...@gmail.com >> > > > > >wrote: >> > > > > >> > > > > > When I first load my page, some form's fields are changed >> through >> > > ajax >> > > > > and >> > > > > > then I submit the form (Without ajax) with empty fields to >> force it >> > > > into >> > > > > > validation errors. But no errors are shown. If just submit the >> form >> > > > > again, >> > > > > > exactly as it was the last time, the errors are shown ! >> > > > > > >> > > > > > That's how I inject my components >> > > > > > private static final int MULTIPLE_BRAS_LOOP_END = 20; >> > > > > > >> > > > > > > @InjectComponent >> > > > > > > private TextField dnsServerField, domainNameField; >> > > > > > > @InjectComponent("testConfigurationForm") >> > > > > > > private Form testForm; >> > > > > > >> > > > > > >> > > > > > I checked the form using .getHasErrors() and it returned true on >> > both >> > > > > > submits. It's only that on the first submit, nothing is shown >> for >> > the >> > > > > > client ! >> > > > > > >> > > > > > I also forced the form into 2 different validation errors and >> only >> > > the >> > > > > > second submission's error was shown, so its not like showing >> > > validation >> > > > > > errors for previous submissions. Even more, this strange >> behavior >> > > stops >> > > > > > after the first submission, everything works as expected ! >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > BR >> > > > > Ivan >> > > > > >> > > > >> > > >> > > >> > > >> > > -- >> > > BR >> > > Ivan >> > > >> > >> >> >> >> -- >> BR >> Ivan >> > >
