sandweb-devel — Development list

Re: [Sandweb-devel] Re: [Sandweb-commit] CVS: sandweb/bin sandweb.cgi,1.88,1.89

[Piotr K. <Pio...@ct...>]

----- Original Message -----
From: "Rob Helmer" <ro...@na...>
To: <san...@li...>
Sent: 10 grudnia 2001 22:19
Subject: Re: [Sandweb-devel] Re: [Sandweb-commit] CVS: sandweb/bin
sandweb.cgi,1.88,1.89


> On Mon, Dec 10, 2001 at 12:56:45PM -0800, Nick Jennings wrote:
> > On Wed, Dec 05, 2001 at 11:42:10AM -0800, Rob Helmer wrote:
> > > it is _really_ annoying when you accidently view/edit a big binary
> > > file.
> > >
> > > For now, viewing or editing non-text files inline is not permitted.
> > > I think the correct way to do this is to ask the user if they are
> > > sure ( maybe even have a checkbox for "Never ask this again"? would be
> > > cool. We need a more generic mechanism, would be a cool pref though ).
> > >
> > > Anyway, I think the user should just see the download button, and
> > > maybe this warning, if the file does not appear to be text.
> > >
> >
> >  Yes I don't see any reason why someone would want to view a binary
file,
> >  however, what If we don't properly identify the file as viewable, but
it
> >  is? How do we determin that at this point in time?
>
> We determine it using Perl's built-in method through the if statement.
> if ( -d $file ) { $file_type = 'directory' }
> elsif ( -T $file ) { $file_type = 'text' }
> elsif ( -B $file ) { $file_type = 'binary' }
> else { $file_type = 'unknown'; }
>
> Perl determines this by seeing if there are a certain number of non-text
> characters in a certain percentage of the file. I forget the exact
> numbers; I remember posting here about this a while ago. It's a pretty
> decent way to do it, it's the only way I know of ( unless of course
> you can identify the file by it's header, or by parsing the contents,
> which we shouldn't get into right now, we can't possibly track down
> and/or identify every kind of binary file ;)
>
> We can just bring up a page similar to view_file.html, but it
> will have the options "download" and "view anyway". If we do it this
> way, I don't see an easy way to save this setting, so it could get
> annoying for a user. Maybe it could be saved in their prefs by
> extension, I think it's a waste to store tons of stuff in the
> prefs though, since they must be loaded every time SandWeb runs.
>
> Alternatively, we could look at whether the repository thinks this
> is a binary file or not ( "cvs admin -b" sets it as such ), and allow

This is the way how old cvsweb works. As I remember there is also
some kind of 'mime.types' config in cvsweb. It has list of supported
file extensions. Since file name is always accessible this could be used to
determine type of particular file. There are some binary formats
which user might want to see, e.g. jpeg. Of course editing of such
files should be dissabled.

> this setting to override what we think the file is. This requires that
> the user either has their CVSROOT config files set up to deal with marking
> certain extensions as binary/non-mergable/etc, or that we provide
> them a way to set this ( we should, just other priorities ).
>
> I think the second way is better in the long run, we should probably
> leave it how it is until the pieces are in place to support binary
> files in general, as this affects conflict resolution and other
> cool stuff.
>
>
>
> --
> Rob Helmer
> Namodn
>
> _______________________________________________
> Sandweb-devel mailing list
> San...@li...
> https://lists.sourceforge.net/lists/listinfo/sandweb-devel
>
Regards,
\\// Piotr Kaminski
//\\ Pio...@ct...

Re: [Sandweb-devel] Re: [Sandweb-commit] CVS: sandweb/bin sandweb.cgi,1.88,1.89

[Rob H. <ro...@na...>]

On Mon, Dec 10, 2001 at 12:56:45PM -0800, Nick Jennings wrote:
> On Wed, Dec 05, 2001 at 11:42:10AM -0800, Rob Helmer wrote:
> > it is _really_ annoying when you accidently view/edit a big binary
> > file.
> > 
> > For now, viewing or editing non-text files inline is not permitted.
> > I think the correct way to do this is to ask the user if they are
> > sure ( maybe even have a checkbox for "Never ask this again"? would be
> > cool. We need a more generic mechanism, would be a cool pref though ).
> > 
> > Anyway, I think the user should just see the download button, and
> > maybe this warning, if the file does not appear to be text. 
> > 
> 
>  Yes I don't see any reason why someone would want to view a binary file,
>  however, what If we don't properly identify the file as viewable, but it
>  is? How do we determin that at this point in time?

We determine it using Perl's built-in method through the if statement.
if ( -d $file ) { $file_type = 'directory' }
elsif ( -T $file ) { $file_type = 'text' }
elsif ( -B $file ) { $file_type = 'binary' }
else { $file_type = 'unknown'; }

Perl determines this by seeing if there are a certain number of non-text
characters in a certain percentage of the file. I forget the exact
numbers; I remember posting here about this a while ago. It's a pretty 
decent way to do it, it's the only way I know of ( unless of course
you can identify the file by it's header, or by parsing the contents, 
which we shouldn't get into right now, we can't possibly track down 
and/or identify every kind of binary file ;)

We can just bring up a page similar to view_file.html, but it
will have the options "download" and "view anyway". If we do it this
way, I don't see an easy way to save this setting, so it could get
annoying for a user. Maybe it could be saved in their prefs by
extension, I think it's a waste to store tons of stuff in the
prefs though, since they must be loaded every time SandWeb runs.

Alternatively, we could look at whether the repository thinks this
is a binary file or not ( "cvs admin -b" sets it as such ), and allow
this setting to override what we think the file is. This requires that
the user either has their CVSROOT config files set up to deal with marking
certain extensions as binary/non-mergable/etc, or that we provide
them a way to set this ( we should, just other priorities ).

I think the second way is better in the long run, we should probably
leave it how it is until the pieces are in place to support binary
files in general, as this affects conflict resolution and other
cool stuff.



--
Rob Helmer
Namodn

[Sandweb-devel] Re: [Sandweb-commit] CVS: sandweb/bin sandweb.cgi,1.88,1.89

[Nick J. <ni...@na...>]

On Wed, Dec 05, 2001 at 11:42:10AM -0800, Rob Helmer wrote:
> Update of /cvsroot/sandweb/sandweb/bin
> In directory usw-pr-cvs1:/tmp/cvs-serv3566
> 
> Modified Files:
> 	sandweb.cgi 
> Log Message:
> 
> it is _really_ annoying when you accidently view/edit a big binary
> file.
> 
> For now, viewing or editing non-text files inline is not permitted.
> I think the correct way to do this is to ask the user if they are
> sure ( maybe even have a checkbox for "Never ask this again"? would be
> cool. We need a more generic mechanism, would be a cool pref though ).
> 
> Anyway, I think the user should just see the download button, and
> maybe this warning, if the file does not appear to be text. 
> 

 Yes I don't see any reason why someone would want to view a binary file,
 however, what If we don't properly identify the file as viewable, but it
 is? How do we determin that at this point in time?

-- 
  Nick Jennings

Re: [Sandweb-devel] Re: priorities

[Rob H. <ro...@na...>]

Rob Helmer wrote:

>>>1) Interact with CLI programs in a generic way ( Expect.pm? )
>>>

Haven't got a chance to look at this again yet. Maybe I'll do it today :)

>>>
>>>2) Create generic location tracking ( cookie? )
>>>

Why not have a Location object, and let it have methods like 
$location->current(), $location->back()
and so forth? It could be global in the CGI, and all cookie handling ( 
even authentication ) could be
handled by individual subroutines when they "register" it, like -

sub browse {
    unless ( $location->current('browse') {
        # user is not authorized!
         set_error('Please log in.');
         login_menu();
    }
}

Instead of having every menu handle cookies.

Also, cookie setting could be handled in the UI.pm, which would greatly 
simplify the creating and
maintenance of subroutines inside the sandweb.cgi

>>>3) Enable multiple repositories ( some global changes needed )
>>>

Haven't looked at this one yet, my last post had some thoughts on it though.

>>>
>So, what I am trying to say is, until this is fixed, the vcs_prefs_menu()
>will always set repo_type = CVS and connection = SSH, because these
>are the defaults hard coded in to the vcs_prefs.html template. Once
>this is dynamically generated, it will be simple to set the current
>value as the default on the pulldown menu.
>
>This will reset these two setting in your repository pref to
>CVS and SSH, while the other input fields are defaulted
>correctly ( text input fields are easy )
>
This bug is fixed. I also fixed the "spaces in filename" bug ( just 
needed to have escape quotes around
filenames in the CVS.pm ), and finally made the CGI's browse() method 
use the file object correctly
( which required making the Browse.pm use it correctly too ;).



--
Rob Helmer
Namodn

Re: [Sandweb-devel] Re: priorities

[Rob H. <ro...@na...>]

Hi Nick!

On Mon, Dec 03, 2001 at 07:09:45PM -0800, Nick Jennings wrote:
> On Mon, Dec 03, 2001 at 05:49:16PM -0800, Rob Helmer wrote:
> > I gained a little ground on the top 3 priorities -
> > 
> > Prefs is not "finished", but it now fully supports one repository
> > per user. I was able to set up pserver access just through SandWeb
> > and use it successfully ( I had to "cvs login" on the command line
> > though, fixing "interacting with SSH in a generic way" will enable
> > us to talk to CVS in a generic way too ).
> 
> I'm curious to know what is keeping prefs from supporting more than one
> repository? I thought the design for the XML file supported any number
> of repositories. Sorry I am not able to work on much but I hope from
> our talk on and off the list that I am helping with design layout,
> if not implementation.

It's not really XML's fault, it's our parsing of it.. :)
The CGI and SandWeb.pm need some rethinking, basically the repository tag
looks like this (for example, set up for my home server):

<repository name="roro" repo_type="CVS" server="roro" username="robert" 
 password="" root="/var/cvs" />

So, we can tell these apart by "name" which is fine. it's possible
to have any number of repositories on a server, so I think having a 
unique id like "name" is important.

However, we get the XML into a hash and see it like this :
$userprefs->{'repository'}->{'repo_type'}
$userprefs->{'repository'}->{'name'}
$userprefs->{'repository'}->{'server'}
(etc)

That's what all our code is configured to use, inside sandweb.cgi
anyway. the CGI gives it to Repository through it's constructor as
a hash value, so we don't have to worry about that or other objects.
It will blindly do whatever we tell it to :) Only SandWeb.pm, Config.pm
and the CGI need to be retrofitted to support multiple repo's ( i think ).

I think if we adapted it to be like this -
$userprefs->{'repository'}->{"$name"}->{'server'}
$userprefs->{'repository'}->{"$name"}->{'repo_type'}
(etc) 

Where $name is the name of the repository. We'd need to
get a list of repository names from $userprefs->{'repository'} in
order to get this info, a couple loops I guess. I just
haven't got around to try it out yet.

> 
> > Also, I spent some time reworking UI.pm so it's _alot_ easier to
> > use. You can just pass "MENU => 'name'" to the UI object, and
> > it will look for $template_dir/$menu.html, no need to make
> > an entry in UI.pm for every single menu. It now just handles what
> > it's supposed to, the sidebar and the general framework.
> 
> This sounds cool. But what about content?

CONTENT => $content

:)

Sorry there's no API docs for UI yet, it's basically
$content="your content" and you simply give any variables
you want replaced in the template to the UI object; it will
pull up the file told to it by the MENU key and pass the rest
blindly through ( which was what is was doing before, but we
were creating a seperate subroutine in UI.pm for each template!
talk about redundancy. I actually barely modified the get_menu()
method in UI.pm; they ALL looked just like that originally, except
that I put in the part about deleting the MENU key/value pair
so it doesn't get passed to the template).

Check out the preferences_menu() in the CGI
for an example of the code. I'll make up some API docs when
it's more solidified ;)

> 
> 
> > So, prefs is not feature complete, but I am going to put it
> > on the back burner. Here's a new priority list :
> > 
> > 1) Interact with CLI programs in a generic way ( Expect.pm? )
> > 2) Create generic location tracking ( cookie? )
> > 3) Enable multiple repositories ( some global changes needed )
> 
>  Sounds like I good list, I think that multiple repositories should
>  just be fixed to get it out the way, it should be trivial. Maybe
>  if I have a sec, I can take a look at it...

Ok, hopefully what I said above about the XML can get you started.

There's another interesting thing with the current vcs_prefs_menu()
( this is where your repository is set up, could theoretically
be used for any number of them ) :

It fills in the default values for everything but the pulldown
menus, as these are a little tricky. I think they should be
generated by the CGI, though, instead of being hard-coded in
the HTML because they define the available version control
systems ( RCS,CVS ) and the available connection types ( SSH,
RSH, pserver, local ). These things should be defined in a 
config file and be dynamically generated, just as the VCS command
pulldown menu on the browse page is.

So, what I am trying to say is, until this is fixed, the vcs_prefs_menu()
will always set repo_type = CVS and connection = SSH, because these
are the defaults hard coded in to the vcs_prefs.html template. Once
this is dynamically generated, it will be simple to set the current
value as the default on the pulldown menu.

This will reset these two setting in your repository pref to
CVS and SSH, while the other input fields are defaulted
correctly ( text input fields are easy )

I'll take a look at this tomorrow, as it's kind of important.. :P



--
Rob Helmer
Namodn

Re: [Sandweb-devel] Re: priorities

[Nick J. <ni...@na...>]

On Mon, Dec 03, 2001 at 05:49:16PM -0800, Rob Helmer wrote:
> I gained a little ground on the top 3 priorities -
> 
> Prefs is not "finished", but it now fully supports one repository
> per user. I was able to set up pserver access just through SandWeb
> and use it successfully ( I had to "cvs login" on the command line
> though, fixing "interacting with SSH in a generic way" will enable
> us to talk to CVS in a generic way too ).

I'm curious to know what is keeping prefs from supporting more than one
repository? I thought the design for the XML file supported any number
of repositories. Sorry I am not able to work on much but I hope from
our talk on and off the list that I am helping with design layout,
if not implementation.

> Also, I spent some time reworking UI.pm so it's _alot_ easier to
> use. You can just pass "MENU => 'name'" to the UI object, and
> it will look for $template_dir/$menu.html, no need to make
> an entry in UI.pm for every single menu. It now just handles what
> it's supposed to, the sidebar and the general framework.

This sounds cool. But what about content?


> So, prefs is not feature complete, but I am going to put it
> on the back burner. Here's a new priority list :
> 
> 1) Interact with CLI programs in a generic way ( Expect.pm? )
> 2) Create generic location tracking ( cookie? )
> 3) Enable multiple repositories ( some global changes needed )

 Sounds like I good list, I think that multiple repositories should
 just be fixed to get it out the way, it should be trivial. Maybe
 if I have a sec, I can take a look at it...
 
-- 
  Nick Jennings
  Namodn

[Sandweb-devel] Re: priorities

[Rob H. <ro...@na...>]

I gained a little ground on the top 3 priorities -

On Fri, Nov 30, 2001 at 03:26:29PM -0800, Rob Helmer wrote:
> > 
> > Finishing prefs and implementing a better location mechanism should
> > probably be at the top of the list, at least for discussion.
> 
> I think interacting with SSH in a generic way is a high priority, too.

Prefs is not "finished", but it now fully supports one repository
per user. I was able to set up pserver access just through SandWeb
and use it successfully ( I had to "cvs login" on the command line
though, fixing "interacting with SSH in a generic way" will enable
us to talk to CVS in a generic way too ).

Also, I spent some time reworking UI.pm so it's _alot_ easier to
use. You can just pass "MENU => 'name'" to the UI object, and
it will look for $template_dir/$menu.html, no need to make
an entry in UI.pm for every single menu. It now just handles what
it's supposed to, the sidebar and the general framework.

So, prefs is not feature complete, but I am going to put it
on the back burner. Here's a new priority list :

1) Interact with CLI programs in a generic way ( Expect.pm? )
2) Create generic location tracking ( cookie? )
3) Enable multiple repositories ( some global changes needed )

SandWeb is starting to get basically useable for simple CVS
tasks, if anyone wants to check out the latest and look for
bugs, be my guest. I'm pretty happy with the overall structure,
minus priorities 2 and 3.

One bug I do know of offhand is handling spaces in filenames;
it seems to break the VCS commands, but it is lower on my
priority list so I haven't taken a look at it yet. diff doesn't
work, but I don't really care until colorized diff is implemented.

If anyone wants to work on these issues, it should be pretty
safe ( in other words, these components probably won't be changing
from under you ;).



--
Rob Helmer
Namodn

Re: [Sandweb-devel] Coding conventions

[Rob H. <ro...@na...>]

Some updates -

On Mon, Nov 26, 2001 at 10:40:32AM -0800, Rob Helmer wrote:
> When the user clicks submit, the form gets submitted back to
> the CGI with action=file and command=created_file. We could
> set yet another hidden variable to catch whether this is the
> beginning or the end of a submit, but I think the past-tense
> subroutine is alot clearer. Please let me know if anyone has
> ideas about this.

Nick managed to convince me that it's simpler to read and
takes less code overall to just see if a file object exists
( or in the case of edit_file or commit, see if the submit button was
clicked ) than to have present/past tense if statements.

> * location is tracked by a hidden input tag. We should either
>   have a cookie to hold this info, or define this in the global
>   template because it is a pain to enter on every  UI call :)

I'm seeing the need for a generic subroutine to take you back
to where you were last.

> 
> * we now support pserver ( note: that is already logged in :) and 
>   local for CVS commands; this is just because I don't know how
>   to catch the password prompt from RCS/SSH or cvs login. Ideas?

I've been playing with the Expect.pm module for Perl, it is OO
which is nice but adds three extra dependencies ( Expect.pm depends
on two other modules ). It is worth it though if it works as
expected ( IMO ). Code reuse is a good thing.

Expect is like a nicer version of the Unix chat command; it lets
you catch password prompts and generally interact with a CLI.

> 
> * ( mentioned above ) UI could probably be slimmed down by a couple
>   orders of magnitude. I've been busy with other stuff, but it's
>   starting to get ungainly, I think it needs to be looked at.
> 
> * the browse page looks really bad in Internet Explorer. I do
>   development with Mozilla so I hadn't noticed, all the table
>   cells are squished together. Can someone look at the browse.html
>   template? 
> 
> * Prefs. Nick got the pref stuff started with the ability to
>   enter full name, we just need to follow up and enable the 
>   user to store repository info here. 
> 
> * Currently, we can only handle one repository entry, and SandWeb
>   applies the rules ( root, repo_type, username, password ) to
>   every file in your sandbox. A good start, but not very useful
>   in the longer term.
> 
> * We currently cannot remove files or folders, because the action needs
>   to be in an html form to catch files that were checked. The precedent
>   set by the file operation commands is to have HREFs, we should
>   probably have a pulldown for VCS actions ( like we do now ) and
>   a pulldown for file operations ( instead of HREFs ).

I added "Select All" and "Clear All" to the browse.html template
as simple javascript functions, I think it's really useful, but
I think 1) we need a javascript function library, I hard-coded
this subroutine into the template and 2) we should have a way
to turn off javascript features for non-javascript browsers.

In this case, I could just use javascript to print out the
HREFs lines that allow the user to Select/Clear All. That way,
if the user does not have javascript there is no way they could
see them. We need to do this across the board for it to be meaningful
though. I don't think the user agent should be required to support
javascript to run SandWeb.

> 
> Finishing prefs and implementing a better location mechanism should
> probably be at the top of the list, at least for discussion.

I think interacting with SSH in a generic way is a high priority, too.

I've mostly been doing bugfixing around the file/vcsaction checkins I made
recently. The next features I implement will be related to the three
top-priority bugs.



--
Rob Helmer
Namodn

[Sandweb-devel] Coding conventions

[Rob H. <ro...@na...>]

Hello,


I started a couple conventions in sandweb.cgi that make alot
of sense to me, and I thought everyone should know what I'm
currently doing to the code ( and how ) :

Since file operations and vcs operations are where users
are ( most likely ) going to be spending most of their time,
I have created two subroutines in the CGI - file() and vcsaction().

Here is an example of how they work :

to create a new file, there is a link in browse.html that uses
a hidden input field to set the action variable to file, and
another to set the command variable to create_file.

These params are passed to the CGI, which catches action=file
and passes the filename and command variables to the file() subroutine. 
file() uses the SandWeb::File object to create a new file object, and
errors out if the file does not exist.  
The file() subroutine then has if/elsif statements to determine 
what command is desired, in this case create_file.

Now, we obviously need info from the user at this point; what
is the filename that they want to create? We are going to assume
that they want to create it in the current directory ( I am
determining "current directory" based on another hidden input,
location ). So, we need a template so we can ask the user what
the name of the file will be. ( BTW - in cases like this we
don't yet have a filename, so the file() subroutine is smart enough
to not create a file object ).

This is done by creating a subroutine in UI.pm, essentially by
copying and pasting an already existing routine ( not sure why
we have this redundancy in here, can we cut this down to one
subroutine Nick? I think it could be done ). This subroutine
specifies a file in templates/, in this case it is called
create_file.html and has a text input field and a submit button,
which the user uses to enter a filename.

When the user clicks submit, the form gets submitted back to
the CGI with action=file and command=created_file. We could
set yet another hidden variable to catch whether this is the
beginning or the end of a submit, but I think the past-tense
subroutine is alot clearer. Please let me know if anyone has
ideas about this.

So, the if/elsif statements in file() catch the command
created_file, which just calls $file->create_file(), and
punts to the browse_menu() subroutine. It passes the current
location ( from the hidden input variable ) so the user
can now see their new file, edit it, whatever.

The vcsaction() subroutine mirrors this behaviour. We have
commit/committed, I envision tag/tagged and so forth to
catch the output of templates.

Also, most of the functions ( in the if/elsif statements ) in file() do
things like view, edit, info, etc. where the filename is
known and the file object is always used. ( BTW - info creates
a repository object and calls vcs->log right now. I am
looking at how to best parse this data ).

So, right now when you click on a file in SandWeb, you should
see CVS log info for the file. Once this is parsed nicely, and
we have colorized diff implemented, we will have parity with
the ViewCVS/CVSWeb programs. Already we are able to edit
and save files, and create new files and folders, and run
most of the basic CVS commands so this will actually put us
way ahead as far as features go :)

Anyway, that's the convention for file and vcsaction, it could
probably be used for many other subroutines, too, but I don't
know how many more SandWeb will need. Hopefully not too many. Please let
me know if anyone has better ideas, so we can implement them soon.

Here are some issues I am looking at right now -

* location is tracked by a hidden input tag. We should either
  have a cookie to hold this info, or define this in the global
  template because it is a pain to enter on every  UI call :)

* we now support pserver ( note: that is already logged in :) and 
  local for CVS commands; this is just because I don't know how
  to catch the password prompt from RCS/SSH or cvs login. Ideas?

* ( mentioned above ) UI could probably be slimmed down by a couple
  orders of magnitude. I've been busy with other stuff, but it's
  starting to get ungainly, I think it needs to be looked at.

* the browse page looks really bad in Internet Explorer. I do
  development with Mozilla so I hadn't noticed, all the table
  cells are squished together. Can someone look at the browse.html
  template? 

* Prefs. Nick got the pref stuff started with the ability to
  enter full name, we just need to follow up and enable the 
  user to store repository info here. 

* Currently, we can only handle one repository entry, and SandWeb
  applies the rules ( root, repo_type, username, password ) to
  every file in your sandbox. A good start, but not very useful
  in the longer term.

* We currently cannot remove files or folders, because the action needs
  to be in an html form to catch files that were checked. The precedent
  set by the file operation commands is to have HREFs, we should
  probably have a pulldown for VCS actions ( like we do now ) and
  a pulldown for file operations ( instead of HREFs ).


Those are the big issues that I am thinking about now. Please let
me know about any ideas you have. I would like to document the coding
conventions, so if nothing else please object to the convention and
suggest something better if you don't like it :)

Also, these aren't ordered by priority. I think we're at the
point where different pieces are segregated enough to allow work
without affecting other pieces, but things like solving the multiple
repository problem and using a cookie for location are still pretty global.

Finishing prefs and implementing a better location mechanism should
probably be at the top of the list, at least for discussion.



Thanks,
Rob Helmer

[Sandweb-devel] File object in use

[Rob H. <ro...@na...>]

Hello,


I've put the file object to use, it is used by the Browse
object to give you filesize and age ( this means the date
of last modification, mtime, not time of creation, ctime, 
it should be very easy to expand the File object API to
support ctime/mtime/atime if we need them all ).

Clicking on a file runs Repository->log( file => filename ),
so it has a vaguely CVSWeb-ish feel ( this info is now
returned as text; it needs to be parsed by the CGI and
have links inserted, then it should provide the same functionality
as CVSWeb/ViewCVS/etc. Oh, we still need colorized diffs. It
may be possible to take CVSWeb's routine and put it into
an object, too ).

The file() subroutine in sandweb.cgi handles
this stuff, and can now handle
viewing and editing of files. If the file does not
appear to be Text, then it gives you a warning but
shows the file anyway. 

View has a non-functional Download button, and Edit
has a non-functional Save button. I want to do some
work to make the file() subroutine more generic before
I implement save functionality ( as this will be useful
for vcsaction commands later ).

Also, things like a cookie to hold the location that the
user just came from would be pretty useful, so I'll
investigate this more too.

The File object also needs some more methods - create_file,
create_folder, remove, copy, and move. Maybe more.
Remove, copy and move need entries in the browse.html
template.

Anyway, if anyone wants to pull the latest CVS sources
and check out what is there that would be cool. For some
reason, none of these functions work with dot files, 
which I'm also investigating ( this is critical for 
manupulating CVS's merge backups ). 

Comments on design, UI or code are encouraged :)



Thanks,
Rob Helmer

[Sandweb-devel] File object API

[Rob H. <ro...@na...>]

Hello,


Here is some documentation for the File object.

Please note that I think the way it deals with
filename/location is wrong, because location is
a full path to the user's sandbox, and filename
contains the path from the sandbox up to ( and
including ) the filename itself.

I will update the documentation when I fix this.
For now, this broken behavior is documented.

I've attached the file, so the formatting won't
get all wonky.



Rob Helmer
Namodn

[robert@namodn.com: Re: [Sandweb-devel] Re: [Sandweb-commit] CVS: sandweb/lib/SandWeb File.pm,1.4,1.5]

[Rob H. <ro...@na...>]

Hello,


I checked in a simple implementation of the File object;
now if you select a file ( or click View or Edit ), a
File object will be created, and the output will be
displayed to you.

Right now, the file subroutine in sandweb.cgi checks
to see if the file is file_type=Text, and won't display it if
it is not. This is only temporary; I'm probably just going
to get the web browser to serve up the file and handle the
mime types if it does not look like a Text file.

I'm going to document the File object and check it
in; I would like to add methods like create() and
move() and remove() and so forth, but I'm going
to just document what is there for now.

I am going to investigate what the performance
penalty would be to have the Browse object
use the File object for file listings; it would
cut out alot of code duplication, and I think
the performance hit will be tiny.

I will post the documentation here when it is finished,
so anyone curious about what the File object does will
know.



Rob Helmer
Namodn

----- Forwarded message from Rob Helmer <ro...@na...> -----

From: Rob Helmer <ro...@na...>
To: san...@li...
Subject: Re: [Sandweb-devel] Re: [Sandweb-commit] CVS: sandweb/lib/SandWeb File.pm,1.4,1.5

This is done.

Any comments on having subroutines in File be
able to take actions on the file? I think it would be
cool, because you could create a file by creating a new
File object and : $file->create(); or remove() or move()
or whatever. 

Also, I am going to add a cookie to record the menu that
the user was just at; this could be useful for all kinds
of "stateful" data, like what the user's location was
in the file browser before they went to another menu
to complete a VCS operation, or to go back to the menu
they were just at if they hit an error of some kind
( right now these get thrown to the "debug" page, which
isn't very friendly to users, but useful for us ;)

So, this is a cookie to store the user's last known location.
A neat side effect is that, with this and the auth cookie,
a user could go to a completely different site, and when
they come back ( if it's the same browser session ) they
can pick up right where they left off.

I'm looking at the way we implement cookies right now, once
I understand the best way to do it I'll add this in. It will
be immediately useful to work with Nick's new debug
code to handle invalid pages and other errors, but I
think we can use it down the road for storing other
kinds of state ( I don't think it's a good strategy to
keep making new cookies when things like this come up;
correct me if I'm mistaken in this strategy ).


On Tue, Oct 09, 2001 at 04:32:40PM -0700, Rob Helmer wrote:
> Ah, ok, I'll just make them public then :)
> 
> 
> On Tue, Oct 09, 2001 at 01:59:25PM -0700, Nick Jennings wrote:
> > 
> > On Tue, Oct 09, 2001 at 10:41:41AM -0700, Rob Helmer wrote:
> > > 
> > > Modified Files:
> > > 	File.pm 
> > > Log Message:
> > > 
> > > added info method, which gives you a hash of all known info on the
> > > current File object.
> > > 
> > 
> >  Rob, this isn't really the way an object is typically done. We should
> >  have methods for every type of info we are going to want to pull from
> >  the file. We should not just get a hash of all known info on the
> >  current file. It's really messy, and leaves much room for error in
> >  other peices of the code.
> > 
> >  All of the methods that I see like _get_owner etc. should really be 
> >  public methods for the user of the file object.
> > 
> > -- 
> >   Nick Jennings
> > 
> > 
> > _______________________________________________
> > Sandweb-devel mailing list
> > San...@li...
> > https://lists.sourceforge.net/lists/listinfo/sandweb-devel
> > 
> 
> _______________________________________________
> Sandweb-devel mailing list
> San...@li...
> https://lists.sourceforge.net/lists/listinfo/sandweb-devel
> 

_______________________________________________
Sandweb-devel mailing list
San...@li...
https://lists.sourceforge.net/lists/listinfo/sandweb-devel


----- End forwarded message -----

Re: [Sandweb-devel] view/edit

[Rob H. <ro...@na...>]

On Fri, Sep 28, 2001 at 03:48:19PM -0700, Nick Jennings wrote:
> On Fri, Sep 28, 2001 at 03:06:46PM -0700, Rob Helmer wrote:
> > it will be able to replace it.
> > 
> > For this to happen, Browse needs to be able to understand
> > what elements are relevant to a particular view.
> > 
> 
>  Hmm, Well if theres no CVS direcotry with certain files in
>  it, then it won't let ou do CVS actions. (and it can incorporate
>  different behaviours for different types of VCS').
> 
> > For example, when you click "browse" on the SandWeb panel,
> > you should see a Browse window, but without the pulldown
> > menu that lets you select VCS commands, and with fewer
> > buttons.
> > 
> > This way, you can Upload and Checkout to your home directory,
> > but no other options.

Hmm... I just checked in a change to Browse so that vcs_commands
and repo_type is passed to it by sandweb.cgi, which gets that
by instantiating a Repository object with the user's current prefs.

I've been reading back through the archives since, and I ran across
this message. It's a bit confusing the way we are using the repository
object in sandweb.cgi, with the above in mind; it seems as if we
should be creating repository objects based on the user's current
directory, and userprefs should only be for *creating a new 
sandbox*, not for determining the current settings.

Note that this will not work with RCS since it doesn't store any metadata
in the sandbox ( like CVS keeps in ./CVS ) perhaps we should create
an ./.RCS dir inside RCS sandboxes to get around it? that makes the most
sense to me right now. We can store sandweb-specific metadata there, and
other programs will ignore it ( because it's a dotfile ).

Anyway, I think it should be easy to make sandweb.cgi support
looking at the current sandbox for clues by looking at the user's
current pwd. Currently, only the browse_menu method has this
information, since it gets passed back to the CGI in the browse
template.

I think this is a good candidate for a cookie - that way, we can
create one repository object at the beginning of sandweb.cgi ( like
we do now ), and give the value of the cookie to it.

Repository could then determine what the root, username, repo_type,
sandbox and appropriate vcs_commands are based on the value of this
"location" cookie.

However, if Repository has this kind of guessing built-in, how
do we create a Repository object suitable for a new checkout? There
wouldn't be any metadata for it to see.

I guess we can Repository's constructor be able to take an
argument called "location", as well as "root", "username", "repo_type"
and "sandbox", and only use guessing if "location" is not null.

This seems weird, because if you did this :

my $repo = SandWeb::Repository->new( location => $location,
                                     root => $root,
                                     username => $username
);

then if $location was not null, root and username would be ignored
and set by Repository itself. Not sure if this is desirable
behavior when dealing with objects, I can't seem to find an
appropriate example in my OO Perl book.. :)

Suggestions? 


Thanks,
Rob Helmer

Re: [Sandweb-devel] Re: [Sandweb-commit] CVS: sandweb/lib/SandWeb File.pm,1.4,1.5

[Rob H. <ro...@na...>]

This is done.

Any comments on having subroutines in File be
able to take actions on the file? I think it would be
cool, because you could create a file by creating a new
File object and : $file->create(); or remove() or move()
or whatever. 

Also, I am going to add a cookie to record the menu that
the user was just at; this could be useful for all kinds
of "stateful" data, like what the user's location was
in the file browser before they went to another menu
to complete a VCS operation, or to go back to the menu
they were just at if they hit an error of some kind
( right now these get thrown to the "debug" page, which
isn't very friendly to users, but useful for us ;)

So, this is a cookie to store the user's last known location.
A neat side effect is that, with this and the auth cookie,
a user could go to a completely different site, and when
they come back ( if it's the same browser session ) they
can pick up right where they left off.

I'm looking at the way we implement cookies right now, once
I understand the best way to do it I'll add this in. It will
be immediately useful to work with Nick's new debug
code to handle invalid pages and other errors, but I
think we can use it down the road for storing other
kinds of state ( I don't think it's a good strategy to
keep making new cookies when things like this come up;
correct me if I'm mistaken in this strategy ).


On Tue, Oct 09, 2001 at 04:32:40PM -0700, Rob Helmer wrote:
> Ah, ok, I'll just make them public then :)
> 
> 
> On Tue, Oct 09, 2001 at 01:59:25PM -0700, Nick Jennings wrote:
> > 
> > On Tue, Oct 09, 2001 at 10:41:41AM -0700, Rob Helmer wrote:
> > > 
> > > Modified Files:
> > > 	File.pm 
> > > Log Message:
> > > 
> > > added info method, which gives you a hash of all known info on the
> > > current File object.
> > > 
> > 
> >  Rob, this isn't really the way an object is typically done. We should
> >  have methods for every type of info we are going to want to pull from
> >  the file. We should not just get a hash of all known info on the
> >  current file. It's really messy, and leaves much room for error in
> >  other peices of the code.
> > 
> >  All of the methods that I see like _get_owner etc. should really be 
> >  public methods for the user of the file object.
> > 
> > -- 
> >   Nick Jennings
> > 
> > 
> > _______________________________________________
> > Sandweb-devel mailing list
> > San...@li...
> > https://lists.sourceforge.net/lists/listinfo/sandweb-devel
> > 
> 
> _______________________________________________
> Sandweb-devel mailing list
> San...@li...
> https://lists.sourceforge.net/lists/listinfo/sandweb-devel
> 

Re: [Sandweb-devel] Re: [Sandweb-commit] CVS: sandweb/lib/SandWeb File.pm,1.4,1.5

[Rob H. <ro...@na...>]

Ah, ok, I'll just make them public then :)


On Tue, Oct 09, 2001 at 01:59:25PM -0700, Nick Jennings wrote:
> 
> On Tue, Oct 09, 2001 at 10:41:41AM -0700, Rob Helmer wrote:
> > 
> > Modified Files:
> > 	File.pm 
> > Log Message:
> > 
> > added info method, which gives you a hash of all known info on the
> > current File object.
> > 
> 
>  Rob, this isn't really the way an object is typically done. We should
>  have methods for every type of info we are going to want to pull from
>  the file. We should not just get a hash of all known info on the
>  current file. It's really messy, and leaves much room for error in
>  other peices of the code.
> 
>  All of the methods that I see like _get_owner etc. should really be 
>  public methods for the user of the file object.
> 
> -- 
>   Nick Jennings
> 
> 
> _______________________________________________
> Sandweb-devel mailing list
> San...@li...
> https://lists.sourceforge.net/lists/listinfo/sandweb-devel
> 

[Sandweb-devel] Re: [Sandweb-commit] CVS: sandweb/lib/SandWeb File.pm,1.4,1.5

[Nick J. <ni...@na...>]

On Tue, Oct 09, 2001 at 10:41:41AM -0700, Rob Helmer wrote:
> 
> Modified Files:
> 	File.pm 
> Log Message:
> 
> added info method, which gives you a hash of all known info on the
> current File object.
> 

 Rob, this isn't really the way an object is typically done. We should
 have methods for every type of info we are going to want to pull from
 the file. We should not just get a hash of all known info on the
 current file. It's really messy, and leaves much room for error in
 other peices of the code.

 All of the methods that I see like _get_owner etc. should really be 
 public methods for the user of the file object.

-- 
  Nick Jennings

Re: [Sandweb-devel] view/edit

[Rob H. <ro...@na...>]

On Fri, Sep 28, 2001 at 04:25:37PM -0700, Rob Helmer wrote:
> On Fri, Sep 28, 2001 at 03:48:19PM -0700, Nick Jennings wrote:
> > On Fri, Sep 28, 2001 at 03:06:46PM -0700, Rob Helmer wrote:
> > > 
> > > Lastly, we need Browse to do this so when you are inside
> > > a sandbox, it can figure out what kind of VCS you are
> > > using and only show relevant commands on the pulldown
> > > menu ( where the selectable VCS actions are ).
> > > 
> > 
> >  Yeah, it can make some educated guesses as to what type of
> >  VCS it's currently in, first by looking for the VCS types
> >  special directories, also by looking in it's internal 
> >  datastruct for the user to see what types of VCS's he has
> >  setup and for which checkouts etc.
> 
> Yes, I was thinking perhaps this could be a method 
> in Repository, like Repository->identifyVCS();
> 
> We can put all the messy details of figuring out what kind
> of VCS we are using there, and it will be available to all
> the other objects that way.

I have been thinking, we have spaces for "Revision", "Age",
"Author" and "Last Log Entry" in the browse template. These
are currently unused.

Our template is cloned from ViewCVS, so we don't really need
all these fields, but I think Revision and Age are 1) important
and 2) easily doable.

If we are using CVS ( which we are targetting as our first supported VCS )
then we can get the current revision and last recorded timestamp
from CVS/Entries.

When a file is clicked on, we can use output from Repository->log
( when vcs_type is CVS, at least ) to get a list of all revisions,
and allow the user to either diff between them, or select
individual files to perform VCS actions on ( this can be done
through a pulldown menu, like it is on the main browse screen ).

So this is all well and good, if anyone has other ideas let
me know. The thing stopping me from implementing ( most ) of
this is the fact that Browse needs to be reworked somewhat,
to support different pulldowns and also to use the File object.

I'm trying to conceptualize this; right now, Browse uses
opendir() to open the current directory ( specified by $location )
and reads out the directory entries. At the moment, it decides
if they are Binary, Text or another Directory, and gives them
a suitable icon.

I could see a File object being created when an entry ( that
does not happen to be a directory ) is clicked on, and then
the reference to the File object is passed to whoever needs
it ( most likely this would be Repository ).

To support this, File should be able to store information
like file_type, location, owner, group, perms, and ( of
course ) filename.

It should then be suitable for things like file i/o ( creating/
moving/renaming ) as well as any VCS operations.

I have made this info storable in the File object, although
it needs a bit more work to be really useful, this should
be enough to get started.

One question : should File also be used for general file i/o
( through methods like File->create() and File->move() and
so forth ) or should this be in a seperate object?

I think it should be in the File object, since we already
have a file it would be intuitive to call operations on
it like this ( shortened in the interest of brevity ):

my $file = SandWeb::File->( filename => "test" );
$file->remove( force => "yes" );

( we could have options like "confirm" that remove could
use to call a pop-up or some kind of dialog, that would
be cool ).

Anyway, I still have to make the VCS-supporting changes
to Browse ( I'm working on it ;), but I'd like to get
this one moving, cause it'll allow us to get some cool
features into browse.

Comments please :)