Accessing client side folder structure

I am not sure if this is the correct forum to post this query

In my Java based Web application, I want to access the client side directory structure. What are my options?

A quick google search suggested ActiveX, Applet etc. Any other options?

A signed Applet or an ActiveX control (if we are talking about IE) are your options. If its for uploading files, a form with an input using a file type will give the user a file picker.

It is not for file upload exactly. It is basically for showing the client machine folder structure from which client can browse the directories and files.

What's the purpose? If it's not for uploading, the results you found are the options. If it's not for uploading, what's wrong with the file explorer already on the client machine?

I am building an application to allow comments at file and folder level. This has a larger use in my application. Think of it like a social network for my file system.....

Telling people *why* you want to do something is always a good idea, because it might generate ideas you haven't thought of.

So basically you want to provide publicly-accessible metadata for data nobody else can access? I'm not convinced a webapp is the best way to do this, but I guess I'd head for an applet if it is.

If I were doing it myself I'd try to tap in to the OS and use a web service rather than using a webapp.

David, sorry if I sounded rude.

Web app is the only option I have got here. But what you say sounds interesting.

Can you please elaborate?

Thanks,
Sid

Nope, you didn't sound rude :)

Check out things like Dropbox, which is a step beyond what you actually need. Basically it hooks into the OS: a file is written to the local dropbox folder, then it gets synced on their machine and all other dropbox machines. In your case it'd be a metadata hook: change the metadata, throw the metadata at a web service that collects it (filename, tags, whatever else you want). The web app would just aggregate the metadata in whatever form you need.

That would be a client dependent approach, won't it? Is it possible to build it without any client dependency? There is to be no program or configuration on client side.
My requirements sound demanding, but they have to be met!!

Yes, that's client-specific (like Dropbox).

Your choices, then, are limited to the ones already mentioned. Although I still don't get the point, and it seems like a *lot* of work for the user if the native metadata can't be retrieved.

Ok, let me explain in detail what I am trying to do...

We are using Subversion as the code repository. What I observed in the large projects, having more than 15 programmers/developers working, that there are a lot of file merge issues. In ideal scenario, one should lock file and work, but that doesn't happen everytime, especially given the tight deadlines to deliver.

I thought of creating a web app, which could bring in the entire Subversion repository, and then users could enter comments at file and folder level to flag that node. The system would not enforce anything, but just show updates for each node. A user can flag a file or folder as locked, but it would be a notional and not a real flag. This is to be integrated in the developer's network. I have the SVN API in place.

The app is to be extended for user machines too, hence needs to be generic. This is more for learning and internal usage, but timelines given to me are like an actual project.

Thanks,
Sid

*YUCK*.

If there are *that* many file conflicts, then things aren't being integrated often enough and/or the code has no regard for separation of concerns. In my opinion you're trying to solve a problem that's already been solved in a much cleaner way.

just give your client a client side file upload java program no need for applets and

bla bla

amrish sharma wrote:just give your client a client side file upload java program no need for applets and bla bla

It's not an uploading application, as the poster explained.

David, you talked about some cleaner ways, can you please elaborate on that?

David Newton wrote:If there are *that* many file conflicts, then things aren't being integrated often enough and/or the code has no regard for separation of concerns.