Re: how to save an image inside an folderish page that hasn't been saved yet?

On 7 February 2014 13:55, Martin Opstad Reistadbakk <martior-z4DKO/[email protected]>wrote:

> 1. is how Archetypes worked. It worked fine, but we ended up
> with unfinished content all over the site, so we started using factories. I
> think most people felt it was a bit of a hack, so when the opportunity came
> to start a fresh, we had separate add and edit forms.
>
> Maybe not worry about this for the beta/proof of concept, and only have
> metadata on the add form?
>

A lot of this depends on the UX of it. In this scenario, the "add" form is
still a view only, it just doesn't have all the fields/details of the edit
form.

You only get unfinished objects if people accidentally create stuff or
create things and then abandon them (if "cancel" doesn't delete the object).

Martin


>
>
> On Fri, Feb 7, 2014 at 1:31 AM, Dylan Jay <djay-n0pU0XVUApFWk0Htik3J/[email protected]> wrote:
>
>> On 6 Feb 2014, at 6:25 pm, Martin Aspeli <[email protected]> wrote:
>>
>> > The idea in the holistic deco design was that you'd get an initial,
>> short add form where you'd pretty much just enter a title and maybe some
>> key metadata, and then the item would be created before you go to the
>> editing interface.
>>
>> What we're aiming for with the new version of tinymcetiles and folderish
>> content is a largely unchanged editing experience. You click add, enter
>> title, description and starting entering content into the visual editor. I
>> think it would be a step back to split that into two forms.
>> We'd either have to
>> 1. add the content at you click "add new > page" and give it a random id,
>> 2. or continue with how it works now, but find somewhere temporary to
>> store uploaded sub-content.
>>
>> I'm not sure what the consequences are if we go for #1. I'm sure there is
>> a good reason we don't already do that right?
>> For the moment the latter seems the safest option as it's the least
>> change from how things work now so I'll explore that.
>> One way to do this rather than storing content directly into
>> plone.app.drafts, would be to create a temporary folder in the users home
>> directory and then use plone.app.drafts to move or delete that content
>> after the add is finished.
>>
>>
>>
>> > --
>> > Sent from Mailbox for iPhone
>> >
>> >
>> > On Thu, Feb 6, 2014 at 12:00 AM, Dylan Jay <djay-n0pU0XVUApFWk0Htik3J/[email protected]> wrote:
>> >
>> > As David points out, even with the idea of a special folder for media,
>> it seems we have strong support being able to contain those inside a page
>> that is being created so this is still a problem that needs to be solved.
>> > It's really two problems
>> > 1. where to store the image temporarily
>> > 2. how to make the upload UI make sense
>> > Since we now support uploading files while creating a new page then
>> same applies to them too.
>> >
>> > I can see that plone.app.drafts could perhaps be made to store content
>> but I'm not sure how it's going to work in turns of the upload popup.
>> > Ideally you'd be able to browse the content hierachy via the image or
>> link popup and see the new content object in the place where you are adding
>> it. I think it should be possible to make that work right? Although the
>> backend doesn't even know the title or id of the new content so that would
>> have be either passed in or done at the javascript level.
>> > Alternatively there could be a special container called "new page" in
>> the UI with a shortcut, and the UI defaults to there.
>> >
>> > or we give up on this whole idea of not creating the content before we
>> edit it. Perhaps we create the content first in the right place but with a
>> dummy name. Save renames it and cancel deletes it? plone.app.drafts is
>> essentially doing the same thing but in a more complicated way. The only
>> difference to plone.app.drafts is that if you neither click cancel or save
>> then you get crap left around the place. But is that such a big deal?
>> >
>> > Dylan Jay
>> >
>> > ---
>> > www.pretagov.com - Secure SaaS for Government hosted locally.
>> > P: +61-2-9955-2830 +44-87-0392-7071 | linkedin.com/in/djay75
>> >
>> >
>> >
>> > On 6 Feb 2014, at 8:04 am, Martin Opstad Reistadbakk <martior-z4DKO/[email protected]>
>> wrote:
>> >
>> > > Strong forces in the computer industry is also moving us away from
>> the filesystem as something we have to deal with. Media files are today
>> mostly handled by media library apps, at least for music, video and
>> pictures. On most smartphones and tablets you don't even have access to the
>> file system.
>> > >
>> > > If we move away from folders with content in them, to folderish pages
>> as the main container, I think we have an opportunity to to re-think how we
>> handle images and files. I am not saying the way I described is the only
>> way, but it is a possible route to explore.
>> > >
>> > > Something that might complicate how we approach this is that there to
>> me at least seem to be two types of media. The ones you care about outside
>> of the context where it is first used and might re-use again or at least
>> want to keep organised somewhere, and the images that you don't care about
>> outside of this context.
>> > >
>> > > Folderish pages will introduce more possibilities of media files
>> getting accidentally deleted, even with link integrity checks (people don't
>> always read and delete anyway). Images have much more places to end up as
>> well when you try and find them. In a project desciption containing one
>> main page and several sub-pages, images for the project can end up inside
>> all the different sub-pages, but might be re-used all over the place.
>> > >
>> > > One thought here is that a medialibrary is just a behaviour you
>> enable on a folderish page. If enabled, they will allow images and files to
>> be stored in them. Then the main project page/folder can have images, but
>> the sub pages not. You could also configure this behaviour more and use
>> folderactions to enable it for newly added pages, so if you want all news
>> content types in the news folder to self contain all images uploaded to
>> them, that would be easy.
>> > >
>> > > Designing a new default way to do handle media in Plone does not mean
>> the old way will go away for those who want that. We are notoriously good
>> at keeping good backwards compatibility, and in the end, they are just
>> content types stored in the zodb.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On Wed, Feb 5, 2014 at 8:34 PM, espen <[email protected]> wrote:
>> > >
>> > >
>> > > 5. feb. 2014 kl. 18:54 skrev David Glick (Plone) [via Plone] <[hidden
>> email]>:
>> > >
>> > >> On 2/5/14, 6:05 AM, Nathan Van Gheem wrote:
>> > >>>
>> > >>>
>> > >>>
>> > >>> On Wed, Feb 5, 2014 at 7:59 AM, Christian Ledermann <<a
>> href="x-msg://6/user/SendEmail.jtp?type=node&amp;node=7570002&amp;i=0"
>> target="_top" rel="nofollow" link="external">[hidden email]> wrote:
>> > >>> -1
>> > >>>
>> > >>> It is quite common (at least in the sites I know) that files and
>> images are associated with a certain content.
>> > >>> e.g. Event -> required reading, outputs, photogallery, ...
>> > >>> I agree. It's one of the advantages of Plone to be able to organize
>> content without having a "Media Repository." If you feel like it'd be nice
>> to have one central place to view and manage media files, you could still
>> create a media repository browser that viewed all content stored in all the
>> folders of the site.
>> > >>>
>> > >> Yeah, storing files and images in a media library and having them be
>> associated with particular content items are not necessarily mutually
>> exclusive. One could make a media library keyed by content UID, for
>> example. (Though I guess that doesn't help with the original question,
>> given that UIDs aren't assigned until content is added.)
>> > >
>> > > consider how one would keep content on a personal computer, ..... plone
>> should do the same.
>> > > Many people would do it like this:
>> > >
>> > > [ myproject]
>> > > [part1]
>> > > [text part 1]
>> > > some_text.rtf
>> > > [images_part_1]
>> > > some_image.jpg
>> > > [part2]
>> > > ........
>> > >
>> > > uploading images is one thing, but deleting them is another:
>> > > If you put all content about for example <<A certain happening>> into
>> one folder, it is easy to remove all at the same time
>> > >
>> > >
>> > > ........ unless the images could be virtually in a folder (they are kept
>> somewhere else, but to the user they appear to be in the folder (some smart
>> folder magic )
>> > >
>> > > Espen
>> > >
>> > >
>> > >>
>> > >>
>> ------------------------------------------------------------------------------
>> > >> Managing the Performance of Cloud-Based Applications
>> > >> Take advantage of what the Cloud has to offer - Avoid Common
>> Pitfalls.
>> > >> Read the Whitepaper.
>> > >>
>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>> > >> _______________________________________________
>> > >> Plone-developers mailing list
>> > >> <a
>> href="x-msg://6/user/SendEmail.jtp?type=node&amp;node=7570002&amp;i=1"
>> target="_top" rel="nofollow" link="external">[hidden email]
>> > >> https://lists.sourceforge.net/lists/listinfo/plone-developers
>> > >>
>> > >>
>> > >> If you reply to this email, your message will be added to the
>> discussion below:
>> > >>
>> http://plone.293351.n2.nabble.com/how-to-save-an-image-inside-an-folderish-page-that-hasn-t-been-saved-yet-tp7569977p7570002.html
>> > >> To start a new topic under Core Developers, email [hidden email]
>> > >> To unsubscribe from Plone, click here.
>> > >> NAML
>> > >
>> > >
>> > > View this message in context: Re: how to save an image inside an
>> folderish page that hasn't been saved yet?
>> > > Sent from the Core Developers mailing list archive at Nabble.com.
>> > >
>> > >
>> ------------------------------------------------------------------------------
>> > > Managing the Performance of Cloud-Based Applications
>> > > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> > > Read the Whitepaper.
>> > >
>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>> > > _______________________________________________
>> > > Plone-developers mailing list
>> > > Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> > > https://lists.sourceforge.net/lists/listinfo/plone-developers
>> > >
>> > >
>> > >
>> ------------------------------------------------------------------------------
>> > > Managing the Performance of Cloud-Based Applications
>> > > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> > > Read the Whitepaper.
>> > >
>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk_______________________________________________
>> > > Plone-developers mailing list
>> > > Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> > > https://lists.sourceforge.net/lists/listinfo/plone-developers
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Managing the Performance of Cloud-Based Applications
>> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> > Read the Whitepaper.
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Plone-developers mailing list
>> > Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> > https://lists.sourceforge.net/lists/listinfo/plone-developers
>> >
>> >
>>
>>
>

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers