search

brackets-archive / bracketsIssues

Archive of issues in brackets.
0 stars 0 forks source link

[CLOSED] Support for server-side frameworks #2220

Open core-ai-bot opened 3 years ago

core-ai-bot commented 3 years ago

Issue by Perkin5 Monday Dec 10, 2012 at 13:30 GMT Originally opened as https://github.com/adobe/brackets/issues/2321

Although Brackets now allows me to enter the base url so I can have an instant preview of simple php pages, it still doesn't cater for MVC design, especially the approach used for popular frameworks. So much development now concerns Codeigniter and Wordpress that support for them is a must.

I would like to be editing a View or a Controller in Codeigniter and see the changes reflected live in the browser. Do you have plans to enable that?

core-ai-bot commented 3 years ago

Comment by GarthDB Monday Dec 10, 2012 at 17:43 GMT

that could be a little tricky, do you think there would need to be an extension specialized for each individual framework, and what happens when they are updated and things are deprecated?

core-ai-bot commented 3 years ago

Comment by njx Monday Dec 10, 2012 at 19:56 GMT

Reviewed. Clarified title to indicate that this is about server-side frameworks (not client-side MVC like Backbone, which we would probably address when we get to live JS development). Marking move to backlog.

core-ai-bot commented 3 years ago

Comment by Perkin5 Monday Dec 10, 2012 at 20:54 GMT

Thx njx for that correction.

I'm absolutely certain that it would not require a special extension for each framework. It would have to assume a local (eg mamp, wamp) server but I can already view changes using the standard 'Save file and refresh browser' technique. It would just be a question of automating that process.

Even without that refinement, I see the seeds of greatness in Brackets - very exciting!

core-ai-bot commented 3 years ago

Comment by GarthDB Monday Dec 10, 2012 at 22:10 GMT

that could be more likely - a refresh the front most tab in chrome on save of any file?

core-ai-bot commented 3 years ago

Comment by njx Monday Dec 10, 2012 at 22:22 GMT

@GarthDB I think we already do that. I believe what@Perkin5 is asking for is a way to have changes update as you type, instead of on save.

@Perkin5, is that right? If so, that turns out to be a potentially tricky problem, much trickier than live CSS. The issue is that we would have to be able to map changes you make in your PHP file to the changes that would end up occurring in the final HTML as rendered in the browser, without actually executing the PHP (or having some way to execute just your changed PHP code in isolation, without actually refreshing the entire page). That seems like it would require us to have some knowledge of the framework, plus some way of exercising the framework code separate from actually running it in the context of the overall PHP page.

I actually think this is more feasible in the context of an app that's taking advantage of MVC, but it's still a bit tricky. Our plan is to first explore this with client-side MVC and templating frameworks like Backbone, Mustache, etc., to see if we can achieve live HTML development with those kinds of transformations, before tackling the server side. (Client-side transformations are potentially easier for us to handle because we can do whatever framework instrumentation or DOM mapping we need to do ourselves, rather than having to figure out how to get a given server to do them.)

core-ai-bot commented 3 years ago

Comment by Perkin5 Monday Dec 10, 2012 at 22:40 GMT

Live preview might be 'too difficult' but instead, if a browser front-most tab refresh was forced every time I saved a page in Brackets, that would be good. That refresh does not happen now because you can't use the live preview for a framework. You could make the refresh behaviour an option. Like most developers my left hand is anyway perpetually hovering over Ctrl-S but having to go to the other screen and refresh the browser every time is a nuisance, albeit not the end of the world.

core-ai-bot commented 3 years ago

Comment by njx Monday Dec 10, 2012 at 22:56 GMT

Ah, I see. We have a card in our backlog for similar issues in Rails/Node: https://trello.com/c/uKewlref -- it sounds like the issue in your case is similar, although I'm not familiar with PHP frameworks so don't know whether it's exactly the same thing. I'll make a note on that card that we should look into whether we could solve that as well.

In your case, is there a "main" PHP file that we could use for live previewing? If so, then the main problem we have right now is that when you try to switch to another PHP file (like, say, a controller or view file), we probably try to switch to "previewing" that file even though it doesn't make sense to preview it by itself. Is that what your'e seeing?

If there isn't a "main" PHP file in your project that we can preview, then we have the additional problem of letting you specify the URL to preview.

core-ai-bot commented 3 years ago

Comment by Perkin5 Monday Dec 10, 2012 at 23:27 GMT

On reflection I don't think you can easily specify the URL for Codeigniter. It looks like this: http://localhost/sitename/contollerName/controllerMethod where the controller method calls the view. The default controller is set up in a configuration file.

No I was thinking of something hopefully much simpler. I'm coding a given page (which might be one of a number of elements that go to make up a view) and I set up the related view in my browser - but not through live preview. When I save the bit I'm working on, Brackets simply refreshes the front-most browser tab, whichever it may be. Because I've set it up to be the right one, I see my change. You might think that is a trivial function but it would save me something like 7 seconds every time I do it - an hour a day maybe?

core-ai-bot commented 3 years ago

Comment by njx Tuesday Dec 11, 2012 at 00:10 GMT

Ah, that makes total sense and is great feedback. Seems like a fairly simple thing we could do. Leaving this as "move to backlog" so we can summarize this idea in a new card.

core-ai-bot commented 3 years ago

Comment by Perkin5 Tuesday Dec 11, 2012 at 11:01 GMT

Can't wait to see future versions - well done!

core-ai-bot commented 3 years ago

Comment by njx Wednesday Dec 19, 2012 at 21:59 GMT

See also the comments in #2404 for more detail on the CodeIgniter use case.

core-ai-bot commented 3 years ago

Comment by Perkin5 Wednesday Dec 19, 2012 at 23:27 GMT

Many thanks for the link - following with interest.

core-ai-bot commented 3 years ago

Comment by toddhlynch Saturday Mar 16, 2013 at 00:31 GMT

I am new to Brackets, so please excuse me if my following suggestion is off base with the direction of the product. But I am interested so, I figured I would chime in. I looked around a little and could not find the following two ideas, so I thought I would share.

A primary difficulty with server processed code appears to be the mapping of the rendered markup back to the original file, and more specifically, the original element.

One idea that immediately comes to mind is a Brackets markup language, which could be used to comment the code in such a way that it is easy to determine where the code was generated. I understand there might be an immediate "impure feeling" backlash to this idea.

For example, if in your PHP (or any language you choose) you rendered:

Code that you wanted to be able to edit....

You would probably want a whole set of tags where you could identify loops, conditional content, dynamically generated content, etc... so the mapping could be really tight.

Then it would be easy to backtrack from the rendered code to the spot in the original file that needed to be updated.

I don't see how you could avoid re-rendering the whole page on each update. One change in server rendered code could change may places on the page.

Another issue that appears to arise, is that while editing in the editor, one php file could be rendered (included) in many places, so clicking CTRL+E would not know which CSS styles should apply.

The concept that I think would be interesting here would be "a working context", which would basically be the server request that represents the context that you want to be working on the current file in. Currently it appears that the only working context is the static HTML file. So if you are working on a PHP file that is included on 10 different pages, you might generate 10 unique contexts, each would be the URL, cookie, and post information that make up the requests for the context. Then, when you click on CTRL+E on an element, it would render the context that you are in (using the server), and using the above Brackets markup that we described before, determine where on the page you are, and provide the style information that relates.

Maybe it could look in all of your contexts at once, so you understand how your change affects everything - but that might be too confusing. And it would take way to long to render all the contexts for the file on every change.

Just my first .02!

Thanks, Todd

core-ai-bot commented 3 years ago

Comment by pthiess Friday Apr 19, 2013 at 20:25 GMT

Reviewed again@njx - looks like https://trello.com/c/uKewlref is not covering this and we want to do here. If you agree please go ahead and add a specific card to Trello.

Thanks a lot.

core-ai-bot commented 3 years ago

Comment by njx Friday May 10, 2013 at 20:15 GMT

Moving to backlog. What we'll do is capture two ideas on the existing card (https://trello.com/c/uKewlref):

  1. Have a way to "lock" or explicitly specify what live preview page to use (so switching files doesn't try to navigate the live preview to a different page), and make it so saving whatever file you're working on refreshes whatever the current live preview page is (we already do the second part to some extent). I think this is pretty much what@Perkin5 was describing.
  2. Have a way to either manually or automatically instrument a server file so that we can map from the source to generated HTML output. This is actually difficult to do, but we're planning to do something similar for client-side transformations of HTML. I think this is what@toddhlynch was describing.

Thanks!