John McKeon | 1 Feb 2010 01:33
Picon

Re: PRFile, MAFileModel and friends

Hi Ross,

On Sun, Jan 31, 2010 at 4:46 PM, Ross Boylan <ross <at> biostat.ucsf.edu> wrote:
I am trying to figure out the relation between PRFile, MAFileModel,
MAFileDescription, and possibly others.  They seem to duplicate a lot of
information, such as mimetype and filename.

I'm using the Pier-1.2 download.

PRFile says it references an instance of MAFileModel, but a lot of test
code for seems to get by without an MAFileModel.

Look at the class side of PRFile. Its in the descriptionFile method. 

I've looked for references to the classes, but have found either
extremely terse and trivial tests or the setupup for, e.g., defaultCSS.

I also don't know which of the classes is intended for display, or how
to display them.

Initially, I just want to use these to display links to files that are
on the disk.  Presumably that will use MAExternalFileModel somehow.

You really don't need to worry about all that in Pier I don't think. Just use the Add command and select PRFile from the combo box. Then edit the page to put a reference to it. Given that it is named MyFile the reference would look like +/MyFile+ (also given that it is added to the root page)

Hope this helps
John


Later on, I may want to have pseudo files that include the ability to
select a format in which to download the file or to display the file
inline on the web page.
 

Ross Boylan

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki



--
http://jmck.seasidehosting.st
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Ross Boylan | 1 Feb 2010 02:32
Picon

Re: PRFile, MAFileModel and friends

On Sun, 2010-01-31 at 19:33 -0500, John McKeon wrote:
> Hi Ross,
> 
> On Sun, Jan 31, 2010 at 4:46 PM, Ross Boylan <ross <at> biostat.ucsf.edu>
> wrote:
>         I am trying to figure out the relation between PRFile,
>         MAFileModel,
>         MAFileDescription, and possibly others.  They seem to
>         duplicate a lot of
>         information, such as mimetype and filename.
>         
>         I'm using the Pier-1.2 download.
>         
>         PRFile says it references an instance of MAFileModel, but a
>         lot of test
>         code for seems to get by without an MAFileModel.
> 
> 
> Look at the class side of PRFile. Its in the descriptionFile method. 
Ah: the file instance is lazily initialized with this, and then
PRFile>>filename: and PRFile>>contents, for example, pass through to the
file instance.
>         
>         I've looked for references to the classes, but have found
>         either
>         extremely terse and trivial tests or the setupup for, e.g.,
>         defaultCSS.
>         
>         I also don't know which of the classes is intended for
>         display, or how
>         to display them.
>         
>         Initially, I just want to use these to display links to files
>         that are
>         on the disk.  Presumably that will use MAExternalFileModel
>         somehow.
> 
> 
> You really don't need to worry about all that in Pier I don't think.
> Just use the Add command and select PRFile from the combo box. 
I need to generate these programmatically by scanning a directory on the
server.

But PRFile itself has no display logic, and so I'm not sure how that
gets hooked up.

Is the idea to add PRFile as a child of the PRPage?
> Then edit the page to put a reference to it. Given that it is named
> MyFile the reference would look like +/MyFile+ (also given that it is
> added to the root page)
> 
> 
> Hope this helps
> John
> 
> 
>         
>         Later on, I may want to have pseudo files that include the
>         ability to
>         select a format in which to download the file or to display
>         the file
>         inline on the web page.
>          
>         
>         Ross Boylan
>         
>         _______________________________________________
>         Magritte, Pier and Related Tools ...
>         https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> 
> 
> 
> -- 
> http://jmck.seasidehosting.st
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

John McKeon | 1 Feb 2010 03:25
Picon

Re: PRFile, MAFileModel and friends



On Sun, Jan 31, 2010 at 8:32 PM, Ross Boylan <ross <at> biostat.ucsf.edu> wrote:
On Sun, 2010-01-31 at 19:33 -0500, John McKeon wrote:
> Hi Ross,
>
> On Sun, Jan 31, 2010 at 4:46 PM, Ross Boylan <ross <at> biostat.ucsf.edu>
> wrote:
>         I am trying to figure out the relation between PRFile,
>         MAFileModel,
>         MAFileDescription, and possibly others.  They seem to
>         duplicate a lot of
>         information, such as mimetype and filename.
>
>         I'm using the Pier-1.2 download.
>
>         PRFile says it references an instance of MAFileModel, but a
>         lot of test
>         code for seems to get by without an MAFileModel.
>
>
> Look at the class side of PRFile. Its in the descriptionFile method.
Ah: the file instance is lazily initialized with this, and then
PRFile>>filename: and PRFile>>contents, for example, pass through to the
file instance.
>
>         I've looked for references to the classes, but have found
>         either
>         extremely terse and trivial tests or the setupup for, e.g.,
>         defaultCSS.
>
>         I also don't know which of the classes is intended for
>         display, or how
>         to display them.
>
>         Initially, I just want to use these to display links to files
>         that are
>         on the disk.  Presumably that will use MAExternalFileModel
>         somehow.
>
>
> You really don't need to worry about all that in Pier I don't think.
> Just use the Add command and select PRFile from the combo box.
I need to generate these programmatically by scanning a directory on the
server.

That would probably take some custom code. Depending on how you would use it it could be a plain old Seaside component (easier) or a Pier component which would be a little more involved.


But PRFile itself has no display logic, and so I'm not sure how that
gets hooked up.

A PRFile is a structure, when added to the tree of structures that make up the site, Pier renders it with the proper PRViewComponent. Pier is very sophisticated that way.

Is the idea to add PRFile as a child of the PRPage?

Yes, exactly. Doing it this way, you can add all the files you like without writing any code. I.e. content management from the web browser. 
  
> Then edit the page to put a reference to it. Given that it is named
> MyFile the reference would look like +/MyFile+ (also given that it is
> added to the root page)
>
>
> Hope this helps
> John
>
>
>
>         Later on, I may want to have pseudo files that include the
>         ability to
>         select a format in which to download the file or to display
>         the file
>         inline on the web page.
>
>
>         Ross Boylan
>
>         _______________________________________________
>         Magritte, Pier and Related Tools ...
>         https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
>
> --
> http://jmck.seasidehosting.st
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki



--
http://jmck.seasidehosting.st
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Lukas Renggli | 1 Feb 2010 07:25
Picon
Gravatar

Re: PRFile, MAFileModel and friends

> I also don't know which of the classes is intended for display, or how
> to display them.

MAFileModel represents a file in Smalltalk. It knows the filename,
mimetype, size, contents, etc. MAExternalFileModel is no different,
other than it stores the file contents externally to the image (see
class comment). The location and naming of this file is managed
automatically, you cannot change it.

> Initially, I just want to use these to display links to files that are
> on the disk.  Presumably that will use MAExternalFileModel somehow.

AFAIK other people have written MAFileModel subclasses that refer to a
specific external file.

Lukas

>
> Later on, I may want to have pseudo files that include the ability to
> select a format in which to download the file or to display the file
> inline on the web page.
>
> Ross Boylan
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

--

-- 
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Ross Boylan | 1 Feb 2010 19:56
Picon

Re: PRFile, MAFileModel and friends

On Mon, 2010-02-01 at 07:25 +0100, Lukas Renggli wrote:
> > I also don't know which of the classes is intended for display, or how
> > to display them.
> 
> MAFileModel represents a file in Smalltalk. It knows the filename,
> mimetype, size, contents, etc. MAExternalFileModel is no different,
> other than it stores the file contents externally to the image (see
> class comment). The location and naming of this file is managed
> automatically, you cannot change it.
> 
> > Initially, I just want to use these to display links to files that are
> > on the disk.  Presumably that will use MAExternalFileModel somehow.
> 
> AFAIK other people have written MAFileModel subclasses that refer to a
> specific external file.
> 
I hadn't realized that MAExternalFileModel was for an uploaded file,
stored on disk.  Making a new subclass to handle files originating on
the server, in "random" directories, sounds straightforward.

I remain puzzled by how to hook these up to output, as well as what the
responsibility of PRFile is.  I've been using a custom component to
display the files, but since PRFile is a model it doesn't seem to belong
there.

I think a natural procedure would be to make a PRPage and then use
addChild: to stick PRFile's into it.  However, the list of files is
dynamic (depending on what's in the directory).  How can I handle that?

Thanks.
Ross

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Lukas Renggli | 1 Feb 2010 20:43
Picon
Gravatar

Re: PRFile, MAFileModel and friends

> I hadn't realized that MAExternalFileModel was for an uploaded file,
> stored on disk.  Making a new subclass to handle files originating on
> the server, in "random" directories, sounds straightforward.

That's the model of a file as a bytearray with a name and mimetype.

> I remain puzzled by how to hook these up to output, as well as what the
> responsibility of PRFile is.  I've been using a custom component to
> display the files, but since PRFile is a model it doesn't seem to belong
> there.

That's the model of a file anywhere in the Pier structure tree. As it
was previously said, it refers to a MAFileModel.

> I think a natural procedure would be to make a PRPage and then use
> addChild: to stick PRFile's into it.

That's what people do when they upload files through the web.

> However, the list of files is
> dynamic (depending on what's in the directory).  How can I handle that?

What directory? In Pier there are only structures that form a
"virtual" directory tree of pages, files, seaside components, books,
chapters, blogs, posts, etc.

Lukas

--

-- 
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Ross Boylan | 1 Feb 2010 20:54
Picon

Re: PRFile, MAFileModel and friends

On Mon, 2010-02-01 at 20:43 +0100, Lukas Renggli wrote:
> > However, the list of files is
> > dynamic (depending on what's in the directory).  How can I handle
> that?
> 
> What directory? In Pier there are only structures that form a
> "virtual" directory tree of pages, files, seaside components, books,
> chapters, blogs, posts, etc.
"directory" refers to a directory on the server's file system. 
The list of files presented by Pier is taken from the list of files in
that directory.  Files will appear and disappear, as well as changing
contents.

So the problem is that if I create a Pier page that is correct at one
time, it won't necessarily be correct, in the sense of matching the
contents of the directory on disk, later.

Ross

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Lukas Renggli | 1 Feb 2010 20:59
Picon
Gravatar

Re: PRFile, MAFileModel and friends

> "directory" refers to a directory on the server's file system.
> The list of files presented by Pier is taken from the list of files in
> that directory.  Files will appear and disappear, as well as changing
> contents.

Ok, I see.

> So the problem is that if I create a Pier page that is correct at one
> time, it won't necessarily be correct, in the sense of matching the
> contents of the directory on disk, later.

Yes, such a use case is not out-of-the-box supported. You'll need to
do some programming here. Depending on how close you want to integrate
it, you can create your own PRStructure subclass that handles this for
you; or, as others already suggested, have a Seaside component that
does something meaningful with the file directory.

Lukas

--

-- 
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Nick Ager | 1 Feb 2010 23:14
Picon
Gravatar

JQuery search widget

Hi,


I've created a PRJQuerySearchWidget as a plug in replacement for the existing PRAjaxSearchWidget. It uses the new Seaside JQuery autocomplete widget, which Lukas has recently added. I implemented it as I'm using other JQuery widgets on my page and didn't want to be without autocomplete search AND I haven't found a satisfactory way to mix scriptaculous and jquery widgets on the same page.

I'll check it in as soon as a couple of fixes go into Seaside: 

Currently if you create an default pier instance with:
   PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel named: 'pier')

..Scriptaculous libraries (if present) are added in PRPierFrame class>>configureApplication:
 
Perhaps we should allow either JQuery or Scripaculous to be specified for this default implementation, or at least add the JQuery libraries (if present), if the Scriptaculous libraries are absent. 

Thoughts?

Nick


_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Lukas Renggli | 2 Feb 2010 08:08
Picon
Gravatar

Re: JQuery search widget

> I've created a PRJQuerySearchWidget as a plug in replacement for the
> existing PRAjaxSearchWidget. It uses the new Seaside JQuery autocomplete
> widget, which Lukas has recently added. I implemented it as I'm using other
> JQuery widgets on my page and didn't want to be without autocomplete search
> AND I haven't found a satisfactory way to mix scriptaculous and jquery
> widgets on the same page.

Pay attention, the JQueryUI Autocompleter and the JQueryUI Buttons are
not fully integrated into Seaside yet. Also they base on unstable
Javascript code.

> I'll check it in as soon as a couple of fixes go into Seaside:
> http://lists.squeakfoundation.org/pipermail/seaside/2010-January/022458.html
> http://lists.squeakfoundation.org/pipermail/seaside/2010-February/022485.html

I will have a look at that today.

> Perhaps we should allow either JQuery or Scripaculous to be specified for
> this default implementation, or at least add the JQuery libraries (if
> present), if the Scriptaculous libraries are absent.
> Thoughts?

I think the default installation should not depend any of these large
Javascript libraries. Pier-Seaside should remain agnostic from the
library used. That's also why we rewrote the editor plugin using bare
Javascript, and not build on top of Scriptaculous.

Lukas

--

-- 
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki


Gmane