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

List:       bricolage-devel
Subject:    Re: [Bricolage-Devel] Request for comments: Local file edition of templates
From:       David Wheeler <david () kineticode ! com>
Date:       2003-09-29 17:09:52
[Download RAW message or body]

On Monday, September 29, 2003, at 08:08 AM, Joao Pedro Goncalves wrote:

> The sandbox is unique per user, and that's the one included:
>
> On checkout:
>
> my $b = Bric::Util::Burner->new({comp_dir => SANDBOX_DIR.
>        get_user_login() });
>    $b->deploy($a_obj);
>
> This deploys the template to the sandbox, but it stays the same
> on the database and everywhere else.

Got it. But why not go ahead and save it to the database? Doing so 
won't affect the existing version, and if the user never checks in her 
changes (say she cancels the checkout altogether), then her changes 
won't affect the existing version of the template at all.

> Then, on preview, SANDBOX_DIR / get_user_login() is included
> in comp_root. That way the template can be previewed only
> for the user that is working on it.
>
> At this point, every preview the user makes that uses this
> template, the code in the sandbox will be used.
>
> When the user finally checks in and deploys the template,
> the sandbox one should be deleted, and preview works with
> the system wide template.

Perfect, nicely done.

> If the user has the template already checked out, edits the template
> in the sandbox and then clicks 'Edit' on the template asset, the
> code that appears there is the one from the sandbox, not the one
> from the database.
>
> From the code:
>
> <%
> escape_html(
>    Bric::Util::Burner->new({comp_dir =>SANDBOX_ROOT})->
>                     get_preview_data($fa, get_user_login())
>            ||
>    $fa->get_data
> )
> %>
>
> $burner->get_preview_data() returns the contents of the file in the
> sandbox belonging to the user.

Right, but I don't see any need for this. Go ahead and save it to the 
database, too. Then all you _really_ need is to save the template to 
the user's sandbox when she saves it, and delete the file when she 
checks it in (or shelves it, or cancels the checkout).

> No - they check *out* and this puts the template in the special 
> sandbox.
> Save should also update the sandbox file - but this could cause sync
> conflicts.

Sounds perfect to me. How would it cause conflicts? Unless you mean 
compared to what's in the database? But as I said, you can still save 
it to the database!

>
>> Throw an exception in this case. What ugly things are you doing?
>
> It's use scenarios.
>
> A user can:
>
> a - edit the sandbox file.
> b - edit in the Template profile page.

Oh, I get it! Please do _not_ let users edit templates on the server 
file system. That's a bad, bad idea.

> Hmn - one could probably create a new flag: Edit in sandbox.
>
> When a template is checked out, if the user checks this flag, he can no
> longer edit it on the web. The template profile page would appear
> exactly the same, except the textarea box would disappear and the
> path to the template file would appear instead. This would solve
> all conflicts while keeping intuitive for the user.
>
> I'll include this feature on the next patch so that you understand it
> better.

No, I would rather not allow users to edit the files on the Bricolage 
file system. Use the virtual FTP server if you want to access stuff 
more directly in your editor of choice (but know that you lose the 
advantages of the sandbox this way).

> User A has access to certain templates, user B to another template set.
>
> If both use the sandbox, both would have access to each other *checked
> out* files.

Yes, so don't let them do that. 'Nuff said.

> The user login is in my opinion more intuitive for the template
> developers.
>
> TEMP_DIR was not used because it needs to be a different value.
>
> I like your 'sandbox' suggestion. TEMPLATE_SANDBOX_DIR probably?
> I'll include that in the next patch.

No, I was thinking it'd just be another subdirectory (for the user's 
login name) in the burner component root.

>> +add_msg("ZBR");
>>
>> What's this?
>
> Thats 'Foo' in Portuguese. Please Ignore :)

Heh, okay.

>>
>> One other thing: This needs to be extended to work for all burners, 
>> not
>> just Mason. Can you do that?
>
> From what Arthur Bergman told me on IRC, Template Toolkit supports
> multiple comp_dir, HTML::Template also supports it by path lookup,
> so should be easy to implement.

Cool, thanks Joao Pedro!

Regards,

David

--
David Wheeler                                     AIM: dwTheory
david@kineticode.com                              ICQ: 15726394
http://www.kineticode.com/                     Yahoo!: dew7e
                                                Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bricolage-Devel mailing list
Bricolage-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-devel
[prev in list] [next in list] [prev in thread] [next in thread]