This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Swing / AWT / SWT and the fly likes Is there a generic File Open/Save/Save As/Close framework? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Is there a generic File Open/Save/Save As/Close framework?" Watch "Is there a generic File Open/Save/Save As/Close framework?" New topic
Author

Is there a generic File Open/Save/Save As/Close framework?

Stevens Miller
Ranch Hand

Joined: Jul 26, 2012
Posts: 523
    
    3

It's easy enough to open and close files, but I find myself rewriting the logic that handles opening a new file when a file is already open and "dirty" (that is, changed-but-unsaved), or closing it, over and over. It would be nice if there were some generic framework I could use for this instead (and, just to be greedy, I'd like something that didn't require me to buy a whole book on it just to open and close files).

I tried Googling this, but my attempts all produced overbroad responses. Turns out to be harder than I thought to form a narrow question involving the opening and closing of files.

What I'd really like is something that handles all the administration of opeining, creating, and closing both named and unnamed files (prompting for a name, that is), obtaining the parameters for a new file (when it has parameters; for example, the dimensions of a new image in a painting program), and graceful cancelation by the user at any point along the way.

Anyone got a pointer to something like that?

Thanks!
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

Stevens Miller wrote:What I'd really like is something that handles all the administration of opening, creating, and closing both named and unnamed files (prompting for a name, that is), obtaining the parameters for a new file (when it has parameters; for example, the dimensions of a new image in a painting program), and graceful cancellation by the user at any point along the way. Anyone got a pointer to something like that?Thanks!


Whenever you feel that something is going against the very fundamental principle of re-usablility of functionality/code, you must try and attempt to write an API for your specific requirement. Perhaps, this particular requirement that you view as a common issue did not prompt the designers to think similarly. Don't you agree that if you try and enclose these 3 operations (opening, creating, and closing both named and unnamed files) in a single API, that would be like bundling many things tightly, which too needs to be prevented in OOP? Wouldn't it be better to keep things segregated?

Having said that, you could argue that having something like struts for handling File I/O operations in Java would be useful. You would have to do some R&D and maybe study if it is worth the effort to be taken as a separate project altogether.


~ Mansukh
Stevens Miller
Ranch Hand

Joined: Jul 26, 2012
Posts: 523
    
    3

Mansukhdeep Thind wrote:Don't you agree that if you try and enclose these 3 operations (opening, creating, and closing both named and unnamed files) in a single API, that would be like bundling many things tightly, which too needs to be prevented in OOP? Wouldn't it be better to keep things segregated?

This collection of operations is nearly universal, and as much so bundled as a set, that I think a single API (to avoid rewriting the same functionality repeatedly) would be useful.
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

You would need to have concrete points to justify why do you think it should be done. See this thread. Here, Winston is attempting to draft a JSR for plugging the gap between a ListIterator and Iterator by something that he proposes to call a DirectionIterator. He would be able to guide you better as to how you should go about drafting and writing a JSR if you really feel it is needed.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41129
    
  45
Mansukhdeep Thind wrote:Don't you agree that if you try and enclose these 3 operations (opening, creating, and closing both named and unnamed files) in a single API, that would be like bundling many things tightly, which too needs to be prevented in OOP? Wouldn't it be better to keep things segregated?

Personally, "no" and "not necessarily". The JRE API should not be taken as the be all and end all of APIs. Quite a few of the earlier JRE APIs were badly designed (which is understandable as at the times nobody had any experience designing Java APIs).

But let's leave the JSR process aside, that's not what Stevens was getting at.


Ping & DNS - my free Android networking tools app
Stevens Miller
Ranch Hand

Joined: Jul 26, 2012
Posts: 523
    
    3

Yeah, I think Ulf is getting my question: I'm not trying to change anything. I'm asking if there is a class out there somewhere that will help me cope with the commonplace paradigm of a File menu that includes the New, Open, Save, Save As, and Close operations we see so often, so I won't have to keep rewriting them all the time. I know there are full-blown application frameworks out there, but I think those are vastly more complicated than what I want. I want something that will help me open and close files, with a sensible path through the various Yes/No/Cancel options that typically confront the user when opening a file when one is already open and dirty, one is not open, one is open and clean and lacks a name, and so on.
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

Stevens Miller wrote: I'm asking if there is a class out there somewhere that will help me cope with the commonplace paradigm of a File menu that includes the New, Open, Save, Save As, and Close operations we see so often, so I won't have to keep rewriting them all the time.

Ulf already said that the current java.io classes are all you need. As for your use case, probably you would have to draft a class yourself for this generic scenario that you would be reusing in the future. Jot down the different operations that you want to be clubbed as a single unit and have a go at implementing it for yourself. Shouldn't be that cumbersome with java.io package at hand. For building the File menu with options that fire these actions you could use SWING APIs maybe to build a UI.
Stevens Miller
Ranch Hand

Joined: Jul 26, 2012
Posts: 523
    
    3

Mansukhdeep Thind wrote:Ulf already said that the current java.io classes are all you need.

I guess I missed where he said that.

If anyone who understands my question can link me to some source code, or a write-up, I'd be most grateful.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

I guess I don't understand the requirement. There's already JFileChooser which as far as I can see handles the bulk of choosing files to be opened or saved to. Perhaps a concrete example of all those other things would help?
Stevens Miller
Ranch Hand

Joined: Jul 26, 2012
Posts: 523
    
    3

Maybe I am overcomplicating it, but here's a case:

User has an unnamed file open and modified in memory.

User chooses File / New from the menu.



Seems to me that the system can be in any one of five states:

1. No file is open.
2. Open file is unmodified and unnamed.
3. Open file is unmodified since last save (and therefore has a name).
4. Open file is modified and unnamed.
5. Open file has been modified since last save (and therefore has a name).

I would like each state to handle the various operations (New, Open, Save, Save As..., and Close), with reasonable logic applied to the questions of saving files, canceling at various points in the transaction, and protecting existing files against inadvertent overwriting. Not all states would permit all five operations, of course:

No file is open --> Only New and Open are enabled.
Open file is unmodified and unnamed --> New, Open, Save As..., and Close are enabled. (prompt for name to give to open file on New, Open, and Close)
Open file is unmodified since last save --> New, Open, Save As..., and Close are enabled. (note that New, Open, and Close don't need to prompt for a file name to give the open file, but the previous state does need to prompt for a file name for these operations)
Open file is modified and unnamed --> New, Open, Save As..., and Close are enabled. (prompt for name to give to open file on New, Open, and Close)
Open file is has been modified since last save --> New, Open, Save, Save As..., and Close are enabled. (note that New, Open, and Close don't need to prompt for a file name to give the open file, but the previous state does need to prompt for a file name for these operations)

A boatload of applications seem to follow the same rubric for this problem. For example, if you open Windows Notepad, it starts you in the "Open file is unmodified and unnamed" state. Type a few characters and it will enter the "open file is modified and unnamed" state. Pick "File / New" from the menu and it will ask you, "Do you want to save changes to Untitled?" Your choices are Save, Don't Save, and Cancel. Cancel takes you back to the initial condition. Save takes you to a "Save as" dialog where your choices are Save and Cancel. Choosing Cancel there takes you back to the initial condition. Save there takes your filename and, if it is already in use, prompts you to say whether or not you want to overwrite the existing file (note that, if you make it this far, you are on your third dialog box, just because you picked "File / New" from the menu in the "open file is modified and unnamed" state; that's a lot of logic to get you to that point, and you still haven't saved your original file).

Does JFileChooser implement all that for me? Far as I can see, all it does is pick filenames, not help me handle the naming of files already open, protect me against reusing existing filenames, and so on. Does it do those things?
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7552
    
  18

Stevens Miller wrote:Yeah, I think Ulf is getting my question: I'm not trying to change anything. I'm asking if there is a class out there somewhere that will help me cope with the commonplace paradigm of a File menu that includes the New, Open, Save, Save As, and Close operations we see so often, so I won't have to keep rewriting them all the time.

Well, I suspect there's a couple of separate things you're asking here:
1. Is there a way of handling these common "lifecycle" actions for a File through a single class? - ie, something like a FileManager (although it's probably a bad name).
2. Is there a GUI component that encompasses the business of a FileManager?

And like Ulf said, I'd look at JFileChooser first for the latter.

As for the first, there may well be; but it's unlikely to be linked specifically to a File; it'll be linked to either a FileReader or a FileWriter, which are the streams associated with a File (File itself is not Closeable).

However, if you're up-to-date and on Version 7, I'd suggest a good look through the java.nio.file package - and in particular the java.nio.file.Files class. It has lots of nice goodies in it.

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

No, JFileChooser doesn't do all of that. But on the other hand I've never ever written an application which did any of that. This of course makes me unqualified to judge its utility. But if it were widely useful, wouldn't there already be an open-source implementation of it? This is Java after all, not Microsoft, so we should expect to find implementations of useful software.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7552
    
  18

Paul Clapham wrote:This is Java after all, not Microsoft, so we should expect to find implementations of useful software.

Ooof. Take that, Bill.

I thought I was the resident MS-basher around here...

Winston
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

Winston Gutkowski wrote:
Paul Clapham wrote:This is Java after all, not Microsoft, so we should expect to find implementations of useful software.

Ooof. Take that, Bill.

I thought I was the resident MS-basher around here... :wink


Wasn't quite meant to be MS-bashing, I rather meant that Java has this "ecosystem" which encourages people to write open-source software around it whereas Microsoft software is more like the "walled garden" which doesn't encourage that as much.
Stevens Miller
Ranch Hand

Joined: Jul 26, 2012
Posts: 523
    
    3

Paul Clapham wrote:But if it were widely useful, wouldn't there already be an open-source implementation of it?

That's exactly what I'm hoping for. By fussing with a few of my commonplace applications (Notepad, OpenOffice.org, and so on), it seems clear to me that the logic of the transactions I've tried to describe is a very common paradigm for any kind of program that is, for lack of a more elegant term, some kind of "editor." At one time, the NetBeans Platform might have been a good example of the paradigm (if not of an implementation), but that appears to have gone the way of all things (at least, it's no longer one of the project types you can create in the NetBeans IDE). But I never got enthusiastic about the NetBeans Platform because it seemed amazingly obscure for what it was; internally, it used some kind of messaging system that was, to me at the time, incomprehensible and very much more complex than what I need.

Since the system I've (admittedly badly) described can be characterized as in one of a finite number of states, I'm thinking the State pattern might be a good foundation. Several of the operations are very much similar between states, so I am thinking that each state's object could be based on an abstract superclass, and make use of the Template pattern. But... just as you say, Paul, this all feels very much like something someone else would have done a long time ago. I'm rather befuddled that I can't just Google up, "simple Java File menu framework" and have source code pouring out of my screen, into my lap, and all over the floor, ready for me to mop it up, wring it out into a bucket, and douse my problem with it.

I mean, fercryinoutloud, it's just Notepad I'm trying to copy. Seems like that ought to be easy (but those are the words that lead to tears, every time, aren't they?)
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7552
    
  18

Stevens Miller wrote:Seems to me that the system can be in any one of five states:
1. No file is open.
2. Open file is unmodified and unnamed.
3. Open file is unmodified since last save (and therefore has a name).
4. Open file is modified and unnamed.
5. Open file has been modified since last save (and therefore has a name).

Hmmm. Seems to me that you're missing one major point here:
"modified" is surely a function of the application, not the File.

Even something as simple as Notepad, which uses the "Open/Save/Save As" paradigm is likely to regard "modified" simply in terms of what's occurred in its current session; and I suspect it'll have absolutely nothing to do with the file on disk (although I could be totally wrong about this - it's been known ).

Secondly: A Java File is NOT an abstraction of a file; it's the abstraction of a name (or URL, or path), with some hooks into the backing system and/or network to check on its status. The mere fact that it has an isDirectory() method is a head's up to that arrangement, as is the fact that you can't close() it. Its associated streams on the other hand...

Now I'm not saying that there isn't something in what you say; just that I'm not so sure that what you'd like is quite as simple - or file-based - as you think.

Winston

PS: It also occurred to me that what you describe above is rarely (if ever) part of the "File / New" function. That is simply a request for the app to create "empty space" or an "empty document" and usually has nothing to do with files whatsoever.
Stevens Miller
Ranch Hand

Joined: Jul 26, 2012
Posts: 523
    
    3

You're right about all that, Winston, but only because I used the word, "file," which I think you have taken to be the same as if I had used the class-name, "File." For this discussion, you can forget all about the JDK class File; in my list of five states, I probably should have said "data structure" instead of "file."

Alas, I appear to have mucked up my description of the problem to the point where I should probably start all over again.

Notepad is the key: I want a Java class that will manage the run-time logic that Notepad applies to its New / Open / Save / Save As menu items. These happen to be under its "File" menu, but I don't care a whit about whether or not any of this implicates the Java File class; that's just an unfortunate coincidence of words.

Anyway, I've spent the last 24 hours searching the Web for this and have found several commentators who lament the fact that such a thing apparently exists for Web applications, but not for desktop applications (am I the last programmer on Earth who writes desktop applications?). Everyone appears to be left to just roll their own, or else their apps just don't have that kind of "editor" interface. I've designed something that might serve in the place of what I have been looking for, and, if nothing else comes along, I guess I'll write it myself. If it works and it doesn't embarrass me, I'll try to remember to post a link to it here.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7552
    
  18

Stevens Miller wrote:You're right about all that, Winston, but only because I used the word, "file," which I think you have taken to be the same as if I had used the class-name, "File." For this discussion, you can forget all about the JDK class File; in my list of five states, I probably should have said "data structure" instead of "file."

OK, but I think that there is actually a "File" (quite possibly a Java one) in that mix somewhere.

Take the basic functions of a File menu:
1. New (create an empty - and more importantly, unnamed - "whatever")
2. Open (Open a named file and convert it to a "whatever")
3. Save (Save "whatever" to an already named file)
4. Save As (Save "whatever" to a specified file)
5. (don't know if you need it, but it's on lots of 'File' menus) Close (save "whatever" AND close the app)

It seems to me that you have two basic choices:

1. Create a FileAction interface, with precisely those methods, that all Applications you want to provide your "tool" for must implement.

2. Create an independent FileAction class that takes a Structure (the "whatever" in the above list) that can be translated to and from streams or Readers/Writers. This would probably take a bit more thought, but could then be applied to any Application that implements a Structure. The application would handle the business of translation (which it would have to do anyway), and your FileAction class all the business of implementing those "menu" methods (except maybe #1), along with holding any names or Paths that might be needed.

I have to admit, I'm not wild about the name FileAction, but hopefully you get my drift. I know I've also missed out a bunch of stuff, but it's probably where I'd start.

Winston
Stevens Miller
Ranch Hand

Joined: Jul 26, 2012
Posts: 523
    
    3

Yeah, #2 on your list of options is what I'm after. Assume, for the moment, that my "whatever" class implements this interface:



The part I am interested in has nothing to do with how that interface is implemented. I'm interested in the logic that governs the transactions between the system and the user before either of those methods is ever called. Again, suppose I have a modified, unnamed "whatever" in memory. I decide to start working on a new "whatever." I pick File / New from my GUI's menu. Notepad (and Word, and OpenOffice.org, and Google SketchUp, and everything else I've tried that has a "New" on its File menu) then asks me if I want to save the "whatever" I already have in memory. If I say "yes," Notepad then asks me for a name to give to the file that will store my "whatever" on disk. If I pick an existing name, it asks me if I want to overwrite that file or not. If I say "no," it takes me back to the file-naming dialog. And so on, and so on. None of this logic has anything whatsoever to do with what my "whatever" is, and nothing to do with how a "whatever" is written to disk (nor how it is read from disk, when I am opening an existing file that contains a "whatever").

I've created flow-charts for the operations that are legal in each of the five states (like I said, not all operations are legal in each state: "Save," for example, doesn't mean anything when no "whatever" is currently in memory). I've also got a point in the appropriate charts where a dialog can be added to the transactions to permit parameters that are specific to a particular type of "whatever" to be entered by the user (dimensions of an image, for example, in a "paint" program). Thus, I think the State pattern will be a sensible way to turn my charts into code, and that the Template pattern will let me add the hooks for dialogs that are specific to a particular type of "whatever," while still allowing most of the generic operations to be implemented independently of whatever a "whatever" is.

It's a good exercise and will be useful for lots of applications down the road. But, as Paul said, I just can't shake the idea that this is precisely the kind of thing that is so frequently needed, and so generic in nature, that someone, somewhere, must have done this already. This does appear to be embedded in some of the various frameworks that are out there (Struts, SAF, the NetBeans Platform, and so on), but all of those seem to be one or more of for-the-Web-only, insanely complicated, or moribund. I just want a nice, tidy little class that handles the logic of the most common form of File menu that one sees in countless desktop applications.

Ah, well... if you want something done right, I suppose.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7552
    
  18

Stevens Miller wrote:Yeah, #2 on your list of options is what I'm after. Assume, for the moment, that my "whatever" class implements this interface:

Whoa right there, hoss. That interface is already leaping to the conclusion that you're going to be outputting to a File, when what it needs to do is convert to/from a stream of some sort. The business of Files is all part of your FileAction class. Separation of responsibility, remember?

The only possible wrinkle I can see is that there's likely to be a difference between a ReadWritable for something like a JPEG, which will probably need to use InputStream / OutputStream, and a "document", which will probably be better done to a Reader / Writer. You might be able to pare it down to a single set of methods by plugging them into InputStreamReader / OutputStreamWriter, but I suspect that the app is probably the best arbiter of which type of stream it uses for conversion (others may disagree though).

The part I am interested in has nothing to do with how that interface is implemented. I'm interested in the logic that governs the transactions between the system and the user before either of those methods is ever called.

Hmmm. Not true, I suspect. It's true that you don't care how that interface is implemented; but you'll certainly need to use it.
For example, I can definitely imagine methods with signatures like:
public final ReadWritable open(URI name)
public final void saveAs(ReadWritable document, URI name)
somewhere in the mix.

I suspect you're concentrating a bit too much on how each dialogue is going to work at the moment. Step back a bit, and work out what you need to do to get from a ReadWritable to a file (by which I mean, a system file). The dialogues will work themselves out; and personally, I'd start out with the simplest ones: Open and Save As.
I suspect you'll find that the others involve using them anyway.

And BTW
<disclaimer>
This is only my opinion. I've never tried it, and others may have already discovered better ways of doing it.
</disclaimer>


Winston
Stevens Miller
Ranch Hand

Joined: Jul 26, 2012
Posts: 523
    
    3

I appreciate the wisdom, Winston, but you really do seem to be uncommonly committed to dragging me off of my question.

Utterly regardless of how a data structure is read into, or written out of, memory, I am solely interested in the logic of the transactions that precede those events. I would be completely satisfied if the implementation of the read/write interface were this:



My question has nothing to do with that implementation. I am looking for a class that manages the user interactions that govern the process of creating/opening/saving/closing files. I am not interested at all in the process itself.

Honestly, you're a great source of guidance for me and I always hope you'll chime in when I ask a question. But I almost think you're pulling my leg ("takin' the piss," is the closest translation, I think) this time.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7552
    
  18

Stevens Miller wrote:regardless of how a data structure is read into, or written out of, memory, I am solely interested in the logic of the transactions that precede those events.
...
My question has nothing to do with that implementation. I am looking for a class that manages the user interactions that govern the process of creating/opening/saving/closing files. I am not interested at all in the process itself.

But if, as I understand your question (and I take that to be: "How do I provide a generic implementation of the most common functions of a 'File' menu") then you most certainly ARE interested in those processes. Not necessarily in their implementation, but in their signature - ie, how they are provided to you, as the implementer of this "tool".
The rest (ie, the dialogues) is ALL implementation.

Honestly, you're a great source of guidance for me and I always hope you'll chime in when I ask a question. But I almost think you're pulling my leg ("takin' the piss," is the closest translation, I think) this time.

I have to admit, I'm not averse to a bit of TTP; but in this case that wasn't my intention - honestly.

Winston
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7552
    
  18

Perhaps this would be a better way to look at this problem:

I am a FileMenu and I need to "talk" to an Application.

That Application will provide me with output streams or I will provide it with input streams, and my purpose is to be the sole intermediary between the Application and the file system (or database, or whatever).

Now: your first task is to work out WHAT needs to be done to ensure that - and that's what I've been trying to give you. HOW (ie, exactly how all this "chat" is supposed to work) comes later.

Hope that clears things up.

Winston
Stevens Miller
Ranch Hand

Joined: Jul 26, 2012
Posts: 523
    
    3

Winston Gutkowski wrote:Not necessarily in their implementation, but in their signature


It truly doesn't matter what those signatures are, so long as the objects can serialize and deserialize themselves. But, if it helps us get beyond it, the ReadWriteable interface I listed earlier would do.
Stevens Miller
Ranch Hand

Joined: Jul 26, 2012
Posts: 523
    
    3

Winston Gutkowski wrote:Now: your first task is to work out WHAT needs to be done...

Like I said, the behavior of Windows Notepad is my WHAT (well, Notepad doesn't have a "Close" item under its File menu; what it does when you click the "X" in the upper-right corner will do in place of that).

I've actually got this all spec'ed out as flow-charts, and it's quite clear that several of them have sections in common. I do think this is a natural for the State and Template GoF patterns. I am just amazed that there's nothing off-the-shelf I can plug in and use.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7552
    
  18

Stevens Miller wrote:Like I said, the behavior of Windows Notepad is my WHAT...

Actually, Notepad is a very specific application, and your subject was "Is there a generic File Open/Save/Save As/Close framework?".

Perhaps wrongly, my assumption was that the key word there was "generic", and that's what I've been trying to steer you towards; but you seem to be fixated on "how am I going to do this?".

And I hate to say, but the answer is: Unless you're only worried about duplicating Notepad, and creating something that only works for it (or something very like it) - by design.

And that doesn't mean flowcharts and dialogues and "what happens here if the user does this" - that's all about HOW - you need to work out the WHAT; and that's not simply a restatement of your subject, it involves analysis: What are the parameters? Who and what are the actors? How "generic" does this tool need to be? What does the "application" need to provide?

And I hate to say, but all the flowcharts in the world ain't gonna help you with that. Some other URL diagarams might though.

Winston
Stevens Miller
Ranch Hand

Joined: Jul 26, 2012
Posts: 523
    
    3

Winston Gutkowski wrote:
Stevens Miller wrote:Like I said, the behavior of Windows Notepad is my WHAT...

Actually, Notepad is a very specific application, and your subject was "Is there a generic File Open/Save/Save As/Close framework?".

Perhaps wrongly, my assumption was that the key word there was "generic", and that's what I've been trying to steer you towards; but you seem to be fixated on "how am I going to do this?".

And I hate to say, but the answer is: Unless you're only worried about duplicating Notepad, and creating something that only works for it (or something very like it) - by design.

And that doesn't mean flowcharts and dialogues and "what happens here if the user does this" - that's all about HOW - you need to work out the WHAT; and that's not simply a restatement of your subject, it involves analysis: What are the parameters? Who and what are the actors? How "generic" does this tool need to be? What does the "application" need to provide?

And I hate to say, but all the flowcharts in the world ain't gonna help you with that. Some other URL diagarams might though.

Winston


Winston, I didn't say "Notepad." I said, "the behavior of Notepad." Which is also the behavior of OpenOffice.org, the NetBeans IDE, and countless other desktop applications. (Each has some distinguishing characteristics, but they all do much the same thing for purposes of my problem.)

I'm having a very hard time understanding what you mean by "what" vs. "how." Seems to me that the "what" is very clear: I want a system that prompts the user to save/discard/cancel a modified and unsaved file (or, if you prefer, "data structure") upon closing it, opening another one, or creating a new one. I want it to confirm overwriting of existing files when unnamed files are saved to names that already exist. In other words, I'm looking for a class that implements the behavior of countless desktop applications' "File" menus. Isn't that the "what"?

Let me put it another way: Have you ever written a program that writes data to a file by asking the user to name that file and, if so, did your program ask the user to confirm that an existing file with that name should be overwritten? If you have, please tell me if you wrote all the code to handle those transactions yourself, or did you use a pre-existing class to do it?

As for flow-charts, there are exactly five states the system can be in: nothing loaded; data loaded, clean, and unnamed; data loaded, dirty, and unnamed; data loaded, clean, and named; data loaded, dirty, and named. In each state, the system must react appropriately to those operations from the list of New, Open, Save, Save As, and Close that are enabled for that state. I have a flow-chart for each state and each operation, all of which end with either a return to the caller or a transition to a new state. They do completely embody the problem and its solution, and I can write code from them pretty directly. I just cannot believe this hasn't been done a million times by other people.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7552
    
  18

Stevens Miller wrote:Winston, I didn't say "Notepad." I said, "the behavior of Notepad."

OK, so we are talking about what you put in your subject.

I'm having a very hard time understanding what you mean by "what" vs. "how." Seems to me that the "what" is very clear: I want a system that prompts the user to save/discard/cancel a modified and unsaved file (or, if you prefer, "data structure") upon closing it, opening another one, or creating a new one. I want it to confirm overwriting of existing files when unnamed files are saved to names that already exist. In other words, I'm looking for a class that implements the behavior of countless desktop applications' "File" menus. Isn't that the "what"?

That's part of it; and it's not a bad start. It defines (roughly) the behaviour you expect, but it doesn't define the data requirements of your framework, or the interaction that you need with either of ts actors (which are, as I see it, an Application, and a User).

Let me put it another way: Have you ever written a program that writes data to a file

Sure. And furthermore, I've written utilities to go through all the stuff you've been talking about. But that was in C and Basic and PL/1 and Progress, which are NOT Object-Oriented languages. It seems to me that you simply want to write a procedural solution in an OO language, and furthermore one who's relationship with the native file systems is, to say the least, "arm's-length".

As for flow-charts, there are exactly five states the system can be in: nothing loaded; data loaded, clean, and unnamed; data loaded, dirty, and unnamed; data loaded, clean, and named; data loaded, dirty, and named.

Have you heard of a State-transition diagram? Because it strikes me as much more appropriate for something like this. Furthermore, I suspect you'll find that there is more that just one flow path.

In each state, the system must react appropriately to those operations from the list

Right. Which is why I suggested that you tackle the simple ones (Open and Save As) first. Because I know darn well that if I was writing this, I'd probably want to reuse that code the most.

Just as a simple example: Save = Save As(unnamed ? Gimme a name() : name)

But hey, this is your project and you've got to do it how you see fit. Maybe a read of my WhatNotHow page will help, but I really feel you're leaping ahead to procedure too soon.

Winston
Stevens Miller
Ranch Hand

Joined: Jul 26, 2012
Posts: 523
    
    3

Winston Gutkowski wrote:Just as a simple example: Save = Save As(unnamed ? Gimme a name() : name)

How does that handle the behavior where a user is being prompted for a name, and decides to cancel the operation? For that to work, Gimme a name() would have to return null (or something that indicated cancelation), which would then have to be treated internally as a special case by Save As(). Nothing inherently wrong with that, but my inclination was to have the name be a private member of the state superclass, and have Save As() just return to the caller if the user cancels the transaction.
Your example shows--quite correctly, I think--that a lot of the transactions can be built up out of parts or all of others. My flow-charts make that pretty apparent. That's why I want to use a Template pattern in my superclass: seems like I can centralize a lot of the transactional code there, with the State pattern injecting the state-specific behavior where needed.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Is there a generic File Open/Save/Save As/Close framework?
 
Similar Threads
Session Listener
How to append data in CSV file using CSVWriter?
how to zip multiple files and directory into one output
Unit testing class that deals with file I/O
bufferedreader