[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quanta
Subject:    Re: [Quanta] different web site root
From:       Eric Laffoon <sequitur () kde ! org>
Date:       2006-07-04 20:10:01
Message-ID: 200607041310.01438.sequitur () kde ! org
[Download RAW message or body]

On Tuesday 04 July 2006 7:12 am, Xavier Brochard wrote:
> Hello Eric
>
> thanks a lot for the long answer

It's what I do. ;-)
>
> Le mardi 4 juillet 2006 08:11, Eric Laffoon a écrit :
> > This is confusing to me. We try to be as flexible as possible, but it is
> > inevitable that some conventions must be used to create some degree of
> > structure. Otherwise everything is a mess.
>
> I agree. Quanta is very flexible. It can be even better :-)

Better is subjective for a million users. I have to be objective.
>
> > Our upload facility uploads to a mirror image of your local structure.
> > Otherwise you would have to make per
> > directory or per file destination assignments and propagate them... which
> > is just ugly.
>
> Agree. But it's the same situation for the special case I described.
>
> > Typically server accounts grant access below the document
> > root which is logically the project root.
>
> This is good if you are creating the web site. But not if you are working
> to change some pages on a big old web site with a bunch of graphic files
> with confusing names..... :-) Joking, but it's really different to work on
> an already created web site, with limited access.

This is why we're working on Team projects, task profiles and access 
management. It will enable a definition of what is to be done to be set by a 
team leader, thus reducing the stimulus delivered to you to specific task 
related assignments.
>
> (...)
>
> > > I can't upload with quanta because if the document root is below the
> > > project root on the local hard drive, that document root will be below
> > > the document root on the web site (because the doument root is also the
> > > ftp root.). Let me explain. See diagram below:
> >
> > Exactly. See above. What would you like us to do that wouldn't be
> > hideously over-complicated?
>
> It will help if we could assign a local root directory for each upload
> profiles (like in ftp clients). It's not a complicated solution and it
> could be a real improvement when working on very big website (in this case
> the upload dialog is slow because Quanta has to verify a
> bunch of files). If you setup a profile with the appropriate local "root
> upload directory", Quanta will need to verify only files in that directory.
> And you can work with different profiles assign to different "root upload
> directory". Just like in all ftp clients.

I think that's a mess. Why don't you just set up multiple projects?
>
> > There are upload managers that may handle this, but it
> > all comes down to how complicated you want things to be. You can also
> > write scripts to shuffle files on upload (believe it or not) with
> > Quanta's Project Event Actions, but we only offer this for the truly
> > massochistic. ;-)
>
> It's ok I'm this sort of guy!
> What is it? I didn't found doc about it.
>
Look in the docs under Advanced Features::Event Actions

While you're at it look at the Team Development, Annotations, Extending Quanta 
and have a look at Kommander. You can literrally create a new version with 
scripting, point and click, visual dialog building and not a single line of 
C++. That was my objective, to service those we could not by giving them the 
tools.

-- 
Eric Laffoon - Quanta+ Team Leader 
http://quanta.kdewebdev.org
_______________________________________________
Quanta mailing list
Quanta@mail.kde.org
https://mail.kde.org/mailman/listinfo/quanta

[prev in list] [next in list] [prev in thread] [next in thread]