On 8. Apr, 2013, at 20:37, Joachim Dreimann wrote: > On 4 April 2013 19:50, Matevž Bradač <[email protected]> wrote: > >> >> On 4. Apr, 2013, at 13:49, Gary Martin wrote: >> >>> On 04/04/13 12:07, Apache Bloodhound wrote: >>>> #471: Merge activity feed + change history >>>> --------------------------+------------------------------------------ >>>> Reporter: jdreimann | Owner: gjm >>>> Type: enhancement | Status: accepted >>>> Priority: major | Milestone: Release 6 >>>> Component: dashboard | Version: >>>> Resolution: | Keywords: ui, comments, change history >>>> --------------------------+------------------------------------------ >>>> >>>> Comment (by matevzb): >>>> >>>> The r1463560 seems to break the newticket page - the ticket form is now >>>> invisible, only the draft preview can be seen. According to the diff, I >>>> gather (not 100% sure) that the form with id "propertyform" was moved >>>> inside a <div py:if="ticket.exists">, which doesn't render when >> creating a >>>> new ticket. >>>> >>> >>> Thanks for spotting that. Just rendering the form in the right hand >> column will probably look a bit odd so I expect to wrap up that form code >> into a <py:def> function to allow it to be placed in different areas >> depending on whether ticket.exists. >>> >>> Cheers, >>> Gary >> >> Sounds good. I was also thinking whether it would make sense to split the >> new ticket >> page from the view ticket page altogether. As it is now, it's sometimes >> difficult to >> move the elements around without running into various issues: (invalid) >> nested forms, >> duplicate element IDs, responsive layout breakage etc. Plus it's also more >> difficult >> to test all the combinations in current state. >> >> -- >> matevz > > > Just to be clear, we're talking about the /newticket page, yes? > https://bh-demo2.apache.org/newticket
Yes - the /newticket page shares the same template with /ticket/<ID>, bh_ticket.html, which then differentiates between creating a new ticket and displaying/editing an existing one using the "ticket.exists" condition. There are 29 such conditions in the template, and it's becoming quite cumbersome to change something without breaking any of the three states of the page. > > I think this should look just like any ticket page in edit state. If the > edit state doesn't make it obvious enough what do to put in information or > change it, we need to improve that edit state. I don't think we need to > maintain two different ones though. That makes sense, although IMO we should still separate viewing the ticket from editing/creating a bit more. To some extent this has already been done using the bh_ticket_box.html subtemplate, maybe we should continue with that. > > - Joe > > -- > Joe Dreimann | *User Experience Designer* | WANdisco<http://www.wandisco.com/> > > @jdreimann <https://twitter.com/jdreimann> > * > * > *Join one of our free daily demo sessions on* *Scaling Subversion for the > Enterprise <http://www.wandisco.com/training/webinars>* > > THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE > PRIVILEGED. If this message was misdirected, WANdisco, Inc. and its > subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. > If you are not the intended recipient, please notify us immediately and > destroy the message without disclosing its contents to anyone. Any > distribution, use or copying of this e-mail or the information it contains > by other than an intended recipient is unauthorized. The views and > opinions expressed in this e-mail message are the author's own and may not > reflect the views and opinions of WANdisco, unless the author is authorized > by WANdisco to express such views or opinions on its behalf. All email > sent to or from this address is subject to electronic storage and review by > WANdisco. Although WANdisco operates anti-virus programs, it does not > accept responsibility for any damage whatsoever caused by viruses being > passed. -- matevz
