New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Have a modern frontend development story #345

Open
disko opened this Issue Nov 22, 2014 · 3 comments

Comments

Projects
None yet
3 participants
@disko
Copy link
Member

disko commented Nov 22, 2014

This still needs to be discussed in detail. However, Kotti does very well as a backend for single page and mobile applications.

For this kind of usecase developers usually have client side build tools like Bower, Grunt, Gulp and so on. This might conflict with how we currently use fanstatic in Kotti. This issue might be resolved by an elaborate section in the docs, maybe we want to consider replacing fanstatic or just dropping it with no replacement.

@disko disko added this to the 1.x milestone Nov 22, 2014

@vanclevstik

This comment has been minimized.

Copy link

vanclevstik commented Nov 22, 2014

I haven't used Kotti for some time now but in a Pyramid side project I was using BowerStatic (http://bowerstatic.readthedocs.org/en/latest/) and it does the job quite well.
It is build by creators of fanstatic and has a lot in common with it, with a change that it uses Bower for actual static dependencies.

Wrapper for Pyramid is also already written (https://github.com/mrijken/pyramid_bowerstatic) and I think it could work very well with Kotti as well.

Downside of it is that it "locks" you to using Bower and not Grunt, Gulp or something else, so that is also something that would need to be discussed.

@disko

This comment has been minimized.

Copy link
Member

disko commented Nov 22, 2014

On 22 Nov 2014, at 14:14, Vanč Levstik wrote:

I haven't used Kotti for some time now but in a Pyramid side project I
was using BowerStatic (http://bowerstatic.readthedocs.org/en/latest/)
and it does the job quite well.
It is build by creators of fanstatic and has a lot in common with it,
with a change that it uses Bower for actual static dependencies.

Wrapper for Pyramid is also already written
(https://github.com/mrijken/pyramid_bowerstatic) and I think it could
work very well with Kotti as well.

Downside of it is that it "locks" you to using Bower and not Grunt,
Gulp or something else, so that is also something that would need to
be discussed.

Yeah, I saw that and also thought at first sight that it might be a good
replacement.

But I think the reality is: people doing serious frontend development do
have their own toolchain nowadays. And that toolchain is very likely
different for different people. And this isn't any Python tool for
sure. So the more I think about it, the more I come to the conclusion
that Kotti should be as simple as possible w.r.t to static resource
management and absolutely technology agnostic. We're competent on the
backend and should've clear opinions about (some) backend technology,
but leave frontend stuff to frontend developers.

@davidemoro

This comment has been minimized.

Copy link
Contributor

davidemoro commented Jun 4, 2015

If we want to achieve the frontend goals for kotti (freedom, technology agnostic, etc) we could provide:

  • an optional package (kotti_backend?) that turns a standard Kotti to a private content manage area
  • a generic base layer that exposes kotti's info (navigation, breadcrumbs, children, etc). I think most of this info could be implemented for free. We should introduce the concept of publishable resources (eg: documents, files, etc) vs not publishable resources (eg: portlet, nav link managers, tabs, etc)
  • a default theme, based on kotti_backend and the generic base layer built with a modern non python frontend toolchain. People could use and customize the default theme or rebuilt from scratch using other frontend tools. With shared auth we can add other more advanced features to the public frontend (admin bar, direct links for editing things, live editing)

It is not a frontend issue, with the backend decoupled from the frontend it is very simple add new features like portlets, navigation link managers, etc.

@disko, how do you consider a backend decoupled from the frontend story for Kotti?

update 20150616: the above approach describes a completely different idea for frontend and backend. It should be better move the discussion on a completely dedicated ticket

update 20150907: I've created kotti_backend (https://github.com/Kotti/kotti_backend) and kotti_frontend (still work in progress but quite promising, see https://github.com/Kotti/kotti_frontend). This approach sounds good for CMS or complete custom web applications

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment