Menu
▾
▴
#29 Change the .wir format to XML
Since an XML parser is required to execute FB, changing the .wir format to XML would help with future enhancements.
I guess a swithc could be added to leave the .wir files as-is and instead support .xml files, but this would give different feature sets depending on the data format being read and saved.
The reasoning for this request is based on my prior request to add an optional FuseAction field to the pages. Enhancements like these would be simple if XML was used here whereas I need to add a new record type to the existing format and cross my fingers that something does not break (I know, I'm exaggerating a bit, but XML would be more standard).
Logged In: YES
user_id=1479959
Originator: NO
Changing the wireframe data file to XML has been on the radar for a very long time. (with respect to this project's life.
Some of the current issues, will simply disappear if we were to get rid of the current text file. XML is a more than adequate substitute and allows for a myriad of secondary tools to be manufactured against the wireframe's XML dataset.
Logged In: YES
user_id=1479959
Originator: NO
Hi Dianna,
I have assigned the actual feature request to you.
We should swap all comments about this task to here.
I will foot note the forum message you started!
Logged In: YES
user_id=1632001
Originator: NO
To All,
Yes, CVS WireFrame Tool 5.01 beta before all else.
I'll be glad to take on the requirements phase. Perhaps we can do a poll of the FB community on several questions about how to proceed. How do we set up polls? Then we can make an announcement on the FB sites.
1. Should wft beta version 5.01 be 'released' before abandoning it?
2. Should the xml version become 'wft v6.0' or should it become a new dev track as 'wftx v1.0'?
3. What features would you like to see added to the wft?
4. Which "deliverables" would you like to see generated by the wft?
I'll take the inputs we gather, pare them down to the top 10(?) items and then ask for a final ok from the community.
Logged In: YES
user_id=1632001
Originator: NO
We should be clear about our ultimate goals. "change the .wir format to XML" in not a goal but the means to reach a goal.
We might set our goals to be to "modernize and enhance the feature set of the wft". By consensus, we will begin by converting the wir-based wft to an xml-based wft. While it is important for all current wir specifications to translate to xml, converting xml back into wir will lose many xml specifications and, as thus, the new tool does not have to be backward compatible. We can create a conversion fuse to convert existing wir files to xml files, and then processing them.
The wir file has this dataset:
[pagetitle]
;page responsibilities
exitlink = destination
menu.link = destination
[[:changedescription:]] <!-- history -->
Which can be translated, minimally, into an xml specification such as...
<wireframe>
<wireframetitle>Wireframe Title Text</wireframetitle> <!-- one per wireframe -->
<page> <!-- one per pagestate in wireframe -->
<pagetitle>
Page Title Text
</pagetitle>
<responsibilities>I do such and such.</responsibilities>
<exitlink destination="pagetitle">Exit Link Text</exitlink>
<menulink destination="pagetitle">Exit Link Text</menulink >
</page>
<history> <!-- one history element per wireframe -->
<event author="developer name" timestamp="time-when-saved">History Event Text</event> <!-- many events per wireframe -->
</history>
</wireframe>
To add 'circuit' and 'fuseaction' for pages and links could be...
<pagetitle circuit="ckt" fuseaction="fa">Page Title Text</pagetitle>
and
<exitlink destination="pagetitle" circuit="ckt" fuseaction="fa">Exit Link Text</exitlink>
I have already created and xml specs file and its dtd for my version of the xml wireframe tool itself, which follows the above convention. If we can come to agreement on the above (or its evolved self), I will upload these files: wireframexml.xml, wireframexml.dtd for the perusal and discussion of the group. These files can be our jumping off point (again, if everyone agrees).
dd
DTD for WFT: wireframexml.dtd
Logged In: YES
user_id=1632001
Originator: NO
File Added: wireframexml.dtd
Proposed XML spec file for WFT
Logged In: YES
user_id=1632001
Originator: NO
File Added: wireframexml.xml
Logged In: YES
user_id=1632001
Originator: NO
I've been thinking about how to do the requirements gathering. First, shouldn't we start a wftx mailing list just for the requirements gathering? Is that you, Gavin? Then we could announce the revived xml project to the yahoo groups list and, from the new list, gather suggestions from the FB community. My personal goal is to get this query to the community by the end of this week (by Friday Oct, 12).
Do either of you have any idea for how long we should keep the window open for requirements gathering: 14 days? 30 days? 60 days? Thirty days seems right, but what do you two think? I've never gathered requirements from fellow engineers, architects and programmers before... Where should we post besides the yahoo groups fb community?
I will put up the first cut verbiage by tomorrow for your perusal and suggestions. Is that okay with you two, that is, do you have the time this week?
dd
Logged In: YES
user_id=1479959
Originator: NO
Dianna,
I have uploaded your two documents into subversion for safe-keeping and version control.
As far as requirements gathering goes....
That can all take place here as part of the task. It really doesn't need a mailing list of its own.
A good place to start (as far as getting word out goes) would be the forums at fusebox.org
You will reach the most number of FB users and more importantly, ones that have a self-interest to assist.
Regardless, I would hate to see your enthusiasm get dampened by a too lengthy a time placed on the requirements gathering phase. - I'd suggest 14 days, with an open mind beyond that - just in case we get a few late comers. - but none the less go at our own schedule.
Proposed DTD v0.2 wftx xml spec
Logged In: YES
user_id=1632001
Originator: NO
Gavin,
Of course! I monitor the fb5 list and that was what I meant. Duh! Thanks. And 14 days it is.
Thanks for putting those files into subversion for me. How do I get started with using it? I used cvs back in the day, if that helps.
I am uploading the next versions. Element names have changed and are incompatible with the first two files and wireframes. For the sake of clarity, I renamed the <page> element to <pagestate>, renamed <pagetitle> attribute 'pageid' to 'pagestateid' and swapped the order of elements <wireframeproject> and <wireframerevision>. I also added a few comments. Have you had time to look at them? Any comments?
About my enthusiasm, I'll dial it back a bit. It is more that I feel the press of time. My health comes and goes and I have been feeling unusually well enough lately that I want to learn as much as I can while I can. Winter is a-coming up here in the Northern latitudes... and I don't do so well in winter.
File Added: wireframexml.dtd
Prposed XML spec for wftx-note dummy info for dev purposes
Logged In: YES
user_id=1632001
Originator: NO
File Added: wireframexml.xml
Logged In: YES
user_id=1479959
Originator: NO
Hi Dianna,
As a previous user of CVS you are pretty much 90% on the way to using SVN fully!
Do a snappy google for tortoise SVN it is a great little SVN tool and it integrates with windows explorer conext menus for updating (reading from) and commiting to SVN repositories.
As far as curbing your enthusiasm goes - don't be silly.... nothing is ever completed by procrastinating. I was actually trying to keep your enthusiasm at a high level by not having any stage simply drag on forever.
I have had a quick perusal of the files that I placed into the repository. It looked Ok tome, especially for a first run.
I'd rather see a "dodgy first run" get off the ground - that can be built on, as opposed to to getting dragged in nothing but the detail and ultimately resolve nothing!
Beau.
Logged In: YES
user_id=1479959
Originator: NO
Sorry everyone,
I just re-read my last post which seemingly has a nonsence last sentence or so.
What I meant to say was;
I'd rather see a version implemented and then built upon, as opposed to getting bogged down in the detail, requirements gathering / arguments over what we do / don't need and ultimately not necessarily get anything productive completed.
Logged In: YES
user_id=1632001
Originator: NO
Hi Gavin and Kevin,
I've had my share of "dodgy first runs"... hmmm... that could be the title of my memoirs, if I write one. ;-)
Here is the notice I am going to post on fusebox5 list. Do you know of other fb lists to post this on?
Kevin Roche, Gavin Baumanis and I have started a conversation about a WireFrame Tool (WFT) wir-to-Xml format (WFTx) conversion project. The first task is to seek requirements from the FB community. What would you like to see changed about, or added to the tool? Do you want to get involved? How should the project proceed?
Everyone with a vested interest is encouraged to join the conversation at:
For the wft project page, go to
http://sourceforge.net/projects/wireframetool
Click on the |Tracker| tab, Select the |Feature Requests| menu item.
From the table, choose: |1725163| Change the .wir format to XML
Or, more directly:
http://sourceforge.net/tracker/index.php?func=detail&aid=1725163&group_id=33502&atid=408530
Some questions are posted to get the conversation started.
Fyi, The WireFrame Tool is (now) a Fusebox5 application for building "clickable" page-for-page mock-ups of a proposed site. A primary use is to aid developer-client communications in the all-important requirements gathering phase.
Logged In: YES
user_id=1632001
Originator: NO
Some question about how to proceed...
There should be at least three discussions:
1. the DTD, or spec, which formalizes contents and format of xml wireframe specifications.
2. the functionality and utility of the WireFrame Tool, itself... what should the wftx be able to do?
3. What outputs should be generated by the wftx...
a. generate circuit.xml files?
b. generate milestone sign-off docs?
c. generate <ul> styled navigation menus?
d. advance site-builder functionality?
Perhaps extensibility deserves a conversation, such as adding functionality via plug-ins, perhaps as a
wir to xml file conversion plug-in.
Here are a few questions that need to be addressed:
1. Should WFT 5.01 beta be released or abandoned?
2. Should WFTx start as version 6.0, to reflect its roots,
or as 1.0, indicating a fresh start with a radically different engine?
3. Coldfusion8 added a number of useful XML functions that are incompatible with other versions.
Which versions of CF should WFTX run on?
Logged In: YES
user_id=1479959
Originator: NO
Hi Dianna,
Don't take my dodgy "keyword" seriously.
But I'm pretty sure you know what I meant.
And your questions are definitely the right starting point in my view.
I'll have a little mull over them today and post a response later this evening.
Beau.
Logged In: YES
user_id=1800975
Originator: YES
Hi all,
I'm excited to see all the dialog going on with this request. I think this is the first open source project that I have added feedback where I received anything more than a canned thank you reply.
As the nutty user that made the initial request, maybe my reason for the request might answer some of your requirements questions. I planned on adding two additional fields to the wireframe definitions: circuit and fuseaction. (pardon me if my terminology is wrong, I'm still fairly new to FB). With this information I was going to add two additional code generation modules in the Generate Code process to create the circuit.xml files and a global xfa.xml and/or xfa.cfm definition file.
In reading some of the latest suggestions, I like the <ul> navigation menu idea, I think it is similar to the xfa definition file I was planning. By "advanced site-builder functionality," would this be the ability to specify fuses with the starting fusedoc notes? If so, this would have been the next items on my Christmas list.
Go ahead, gasp, laugh, correct my grammar -- I'm here for the abuse. It's the least I could do since I opened this can of worms!
Logged In: YES
user_id=1632001
Originator: NO
Hi Shifty...
Wow, a fun new project AND someone to abuse! Life doesn't get much better than this! Thanks for starting this feature request. You can blame Jeff Peters for getting me started... I wanted to learn fb5, so I bought his book. I also wanted to learn xml on cf, so I bought another of his books. Then I found the wft...
'circuit' and 'fuseaction' attribute identities were the first things added to the xml specification file. The idea was that after the requirements gathering & wireframe milestones have been signed off, the architect/designer/coder can add the info required before generating the code. This gives the wftx two distinct uses... creating a page-for-page clickable wireframe to aid the communications between the developer and the client. The other use is entirely for the benefit of the developer... fb code generation. We need to keep those two rolls in mind.
Btw, generating the xfa fuseactions with the <ul> html menu is a good idea... consider it on the requirements list. I had also thought about adding a 'fusename' attribute in the <pagestate> element.
Right now, I'm thinking about how we name all these related fusebox entities... for instance, when the developer (whoever) enters a new pagestate title, a copy of that string has spaces removed and set to lower case to become the pagestateid... 'Home Central' becomes 'homecentral' plus it can become a fuseaction 'wireframe.homecentral' or 'xfa.homecentral' and the fuse could be named 'dsp_homecentral.cfm'. Being attributes of the same element, editing the pagestate title would force changes to pagestateid and fuseaction (and fusename?) values. And you should be able to turn off all automation when you want to.
I originally thought of the code generator output as one large file with all the components of the new wireframe in it. But, I can see how we can create the bare bones directory structure and populate it with empty fuses. We should coordinate this with the fb5.5 team. A wireframe that automatically generates code isn't much good if the output is out of step with the fb core file advancements.
To Gavin: "Dodgy first run" is forever in my lexicon. It's a great phrase. It conveys much in a few artful words. We U.S. types seldom use the word dodgy... so it sounds queer (a word that changed meanings within my lifetime) to our ears.
Logged In: YES
user_id=1800975
Originator: YES
I like. Going a little further and generating the bare bones fuses like in your example dsp_homecentral.cfm, maybe instead of an empty fuses, the application would mimic the wireframe output. In essence, the Code Generation step would produce the two code bases: the stand-alone wireframe that it currently creates and a FB based application that mimics the wireframe.
Going this route, then next logical step would be to allow merging changes so as the application matures and new features are added, the original wireframe design could still be used -- for the architect, client and the developer. The merge would create missing fuses, overwrite unmodified wireframe base fuses, and only update the fusedoc section of modified fuses (this third option being the trickiest).
What I just described is a problem I have with the current tool I use - Adalon. Once the design is approved and coding starts, the design and the application go different directions.
Logged In: YES
user_id=300332
Originator: NO
Before we go too far down the path of making the wireframe tool do everything we should consider if it is necessary or desirable to do that.
One possibility is that output from this tool could go to another tool which would do the next step. One of the nice things about an XML file format is that other tools can read it.
There is a project underway (Lead by me) to add a scaffolding code generator to the Fusebox 5.5 release. It is possible that this code generator could read the wireframe XML and generate code for an application. Ok so we now have tow ends of the process what goes in the middle?
[Operating in Devils Advocate Mode] I am generally in favour of keeping things simple and it seems to me that maybe we should just have the wireframe tool do pretty much what it does now with a few extras and build a new tool to do the next steps like the circuit and fuse definitions.
This has one big advantage in that folks are not forced to use all of it.They can use the part they want and leave others behind. I know Jeff Peters for one likes to do that step with a Mind Mapping tool (which I hate). There could be a way to read and write the mind mapping files from the Wireframe XML for those that want that.
What are your thoughts?