Yes, OK, may be a tree view would have its uses, but still it should only relate to document concepts not format tags and attributes. Its just when the term "XML editor" is used then I think of something to edit the actual tags and attributes present in the file.
Michael Whapples On 03/01/2013 16:16, Keith Creasy wrote:
Understood Michael. I actually think a tree view would be a great addition to BrailleBlaster. Not for XML editing exactly but rather to make jumping to specific points in the document. No one need understand that it represents an XML tree, it's just a way to move to different headings, tables, lists, etc. I have even invisioned a way to switch it so that it could show only headings or only images for example. For the rest, I agree that regular users don't need to see actual XML tags and attributes unless they specifically want to do that. Keith Creasy Software Developer American Printing House for the Blind KCreasy@xxxxxxx Phone: 502.895.2405 Skype: keith537 -----Original Message----- From: brailleblaster-bounce@xxxxxxxxxxxxx [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Whapples Sent: Thursday, January 03, 2013 10:20 AM To: brailleblaster@xxxxxxxxxxxxx Subject: [brailleblaster] Re: Different Approaches to document processing. OK, I think an example of where precision of terms might be useful. When I said XML editor, I meant an editor where the user is dealing with the XML format directly, either by typing actual XML, viewing it in a treeview, or some other representation. The type of editor I feel BrailleBlaster should have is a WYSIWYG editor, it should almost be like using something like Wordpad, OpenOffice, Word... insert your favourite WYSIWYG word processor. The above also goes with what I was saying about the document interface, the user should only think about inserting a new column in a table, not that they need to add an additional td element to each tr element inside a table element, if they are dealing with HTML, could very well be different for other formats. Other design patterns, well the adaptor patternn seems relevant if going with my idea that there is a single document interface, we need something to adapt between actions done to the standard document interface and the specific format. Also such an approach might mean that non-XML formats could be handled (although it might lead to interesting things for how to handle UTDML on those formats). The factory pattern could very well be useful for getting the correct adaptor for a particular format. The observer pattern might be relevant for letting the views know that the document has changed and that they need to be updated. I think I have seen quite a lot of static stuff in the code, should that really be static or might singletons be better? I think probably the singletons. There probably are other design patterns which may be relevant/useful, the above are just a few which come to mind. I also have concerns over whether there is sufficient separation of concerns and attempts to maximise reuse. Certainly the reuse one is something I have raised in the past as I feel liblouisutdml and BrailleBlaster are both trying to do the same thing and so leading to duplication, but those concerns were put to one side as reuse was said to not be a concern worth persuing. I would need to look back through the list archive to find out what specific process was being duplicated, although memory is saying it might be in the area of document handling and knowing how to process certain file formats as semantic actions are for the file format. Michael Whapples On 03/01/2013 14:50, Keith Creasy wrote:Michael. What other design patterns/practices do you think we should consider? Yes, I agree 100% that whenever possible we should use established mainstream design practices and standards, like MVC CSS, and XSLT, because a lot of developers already know and understand them. About XML editing, don't confuse the term XML Editor" with something that has to be complicated and technical. It can still be fairly simple. Also, I've always felt that it should be something that doesn't have to be used by people who just want to write and print braille. Since we are editing XML (UTDML) then one could posit that BrailleBlaster is an XML editor whether it appears that way or not to users. Keith Creasy Software Developer American Printing House for the Blind KCreasy@xxxxxxx Phone: 502.895.2405 Skype: keith537 -----Original Message----- From: brailleblaster-bounce@xxxxxxxxxxxxx [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Whapples Sent: Thursday, January 03, 2013 9:36 AM To: brailleblaster@xxxxxxxxxxxxx Subject: [brailleblaster] Re: Different Approaches to document processing. Hello, I have had some concerns over the design of BrailleBlaster for a little bit, that is partly why I decided to keep away from dealing in the code too much and restrict myself to managing the project site and repositories. Keith I know you mentioned about MVC, yes that probably would be a good idea, but may be BrailleBlaster needs to make use of other design patterns and other good practice as well. By neglecting these things its probably made the code and design much harder to follow and means that where one might use standard terms these might not apply or may even have a different meaning and so leading to miscommunications. Regarding the use of semantic actions, I would dispute the arguement that they are easier to use than XSL. My reasoning here again goes along the line of using something familiar to people, XSLT is widely used and so potential developers may already be familiar with it, should one have a difficulty in making it do what they need then it is much more likely they will find an answer (even if the answer is "not possible") by searching the internet as there is much more information out there on XSLT. Keith you mention about defining a document interface, yes this is something I have felt for some time, the view should have no need to understand the underlying document format, it should deal with a single document interface which through various adaptors/providers will modify the document in the appropriate way. As an example, the view should only deal with headings, it should not be concerned with how HTML or DocX store a heading. My understanding at present is that the semantic actions miss out the document interface stage, mapping straight from a file format to how they should be presented. This step really should be split, actions for adapting the format into the document interface and actions for how the view will render the document structure element. The former of these would not need to be customisable by users (only developers who want to add support for additional formats need work with it), whereas the latter would be desirable to be customised by users (eg. sighted users may want headings shown in a different colour, but those who are colour blind may wish to configure it so that headings can be distinguished without the use of colour). If one does not separate these concerns then users may need to deal with every file format they wish to use, meaning additional work for the user and potentially requiring them to have fairly advanced knowledge we really should not expect of users. As for whether BrailleBlaster should have a XML editor, my view would be not. Such an editor would be contrary to the initial aims of BrailleBlaster being easy to use by those with little computer knowledge (IE. not expect more knowledge than knowing how to use a word processor like Word), as an XML editor would require understanding of the underlying XML format. As mentioned, if someone wishes to have such an editor then there are probably other tools more suited for doing that XML editing. Also I feel by spending time on features not really adding to what BrailleBlaster is aimed to achieve will just delay BrailleBlaster ever reaching the goal of what we want it to be. I know some may feel I possibly have a restricted view of what BrailleBlaster should be, my response is that I feel keep it focused to do a particular task for a particular type of user and do that very well. If one tries to make something which is everything for everyone, then it runs the risk of actually not working well for anyone (IE. its too complicated for beginners and have annoying features for experts). There is certainly some software I can think of which falls in the category of trying to be everything to everyone but not working well for anyone, where competing products while more restricted work far better. There possibly is more, but I possibly have raised it in the past with little affect. So in that spirit, I have pretty well said what I feel, unless further discussion would go anywhere I don't really have much apitite to get into big discussions now. In general I think Keith is making some reasonable points. Michael Whapples On 03/01/2013 12:45, Keith Creasy wrote:Yes, I've read the comments in the code and your architecture file. Very helpful. We need to work on the interface between the views and the document. That probably means defining a document interface and a view interface that is XML centric. John, I'm not sure what anyone else can contribute since you want control of the word processor and the document model. Until those are fleshed out there's not really much anyone else can do. At least, speaking for myself, I can't think of anything substantive I can contribute. I'm beginning to think that an XML editor really has no place here. Anyone can just use an external XML editor if they need to do that. Keith Creasy Software Developer American Printing House for the Blind KCreasy@xxxxxxx Phone: 502.895.2405 Skype: keith537 -----Original Message----- From: brailleblaster-bounce@xxxxxxxxxxxxx [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer Sent: Thursday, January 03, 2013 1:50 AM To: brailleblaster@xxxxxxxxxxxxx Subject: [brailleblaster] Different Approaches to document processing. Hi Keith, Yes. Please do outoline your approach. There may be some here who are not acvaquaintged with it. My approach is described in detail in the files in the documentation directory of the brailleblaster.newdesign repository. In addition, Semantics.java contains considerable documentation in the form of javadoc comments. Thanks, John -- John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc. http://www.abilitiessoft.com Madison, Wisconsin USA Developing software for people with disabilities
