Looking for help to properly put dialogs inside Shadowbox container
|
Serge D
Joined: 2009-06-11
Posts: 2466 |
Posted: Mon, 2009-08-31 18:40
|
|
A little bit new area for me, so I want to ask for help here Any suggestions, help are welcomed. |
|
Posts: 16504
So are you trying to replace jquery with shadowbox?
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 2466
I do not think it is right question.
ShadowBox internally could use jQuery if enabled for the web-site, as it would use any other framework. SB is the nice JS extension library which allows to work with different media types on the web-site.
So, I am not trying replace jQuery, but I am trying replace some of the internal JS used by G3.
In this case I need to replace how images (full image (implemented already)) and dialogs (exif info (implemented), login, user data, etc) are displayed to take advantage of SB functionality.
Posts: 2466
There is some discussion with SB theam
http://n2.nabble.com/Ajax-login-form-and-ShadowBox-tp3531644p3531644.html
Posts: 16504
I may not fully understand (not a programmer), but I better understand and will try pointing the devs over here so they can see what you're trying to do and see if it's something simple you need to do or if the core code would need to be modified to make something like this easier for themers.
Thanks
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 2466
Just to give you a "dev" description:
There is a theme I created (see here. It uses ShadowBox module (included) and it is barebone theme with minimum to none of original CSS and JS - can be seen here.
Instead ShadowBox is used where necessary. I've got "Full image" link working properly. There is some small changes required for "Exif data" popup.
But then there are Login and User Data dialogs, which are not just pages, but partial HTML JSON enabled forms which require loop back handling when user submit data. There is G3 JS file which "hacks" the page content on-the-fly and attaches itself to the form submit. Well, this script does not work if dialogs are handled by some other framework (in this case SB).
It would be easier if result of submit would be handled not via JSON (cool, but adds complexity and strips flexibility as demonstrated by situation I have run into) but in "regular" way by navigating to a new form.
Another approach could be to use IFRAME and forms presented as full qualified HTML which would allow to have javascript be embeded into that form page instead of main page form is invoked from. Then JSON could be used there properly and independently, would allow easier theme modifications.
I hope I have explained a little better.
Posts: 238
Serge D, your theme is looking very nice. JSON provides a lot of flexibility and benefits. It's not likely that the current JSON response approach will be altered.
Support the Gallery project with a donation
--
2tbsp.com
Posts: 2466
@thumb, I am not arguing use of JSON here, but rather argue that current implementation (partial forms HTML) is limiting customization possibilities.
Could we keep AJAX/JSON logic but move dialogs to be full flesh html pages which are then embedded by the means of IFRAME?
Otherwise we need more clear path of incorporating current JS handling in non "default" theme based situation.
Posts: 225
Forms are sent as HTML. The Forge form is converted to HTML before it is sent across the wire. It's the results of form submissions that are sent as json.
That said it is hard to customise dialogs with the current version as you can't add your own design bits and bobs to dialogs without having to override large sections of code. It's an area I've struggled with and still haven't got right in the theme I've developed... thankfully I only needed the login dialog to be available to the general public on my theme..
Ben
Benjamin Albert Smith - Photography
Posts: 16504
What exactly would need to be overridden? I've been learning about Kohana's cascading file system and according to bharat, because of that system, a theme should be able to override anything. I know it can override views and apparently it can override helpers. Haven't dug into much else to figure out how to override other components.
Don't know if this would help Serge D's issue though.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 225
To be honest, I'm not really sure how best to do it. To have full control on how forms are converted to HTML you'd probably have to override the Forge Library... which I believe is an always installed module.. So you'd have to create new versions of the Forge_XX.php and stick them in a libraries directory under you theme (if libraries are overridden by the theme as well, which I assume they are). Each element has a render method that I believe will return the html.
Actually.. scrap that above... looking at the code I think you can customize how forms are created. The main render method of Forge has parameters asking for custom templates. I have no idea how this works though.. I'm guessing Forge is a Kohana thing so there may be documentation there...
**brief internet search later**
mentions it at the bottom of this page here..
http://docs.kohanaphp.com/addons/forge
Though the method has changed to render. I think in most places in the g3 code it just uses the toString method of the Forge object to convert to html. You could override the Forge object itself (Forge.php) and pass in custom templates in the toString depending on the form being created... you can check the $this->attr[id] to work out the type of form that the forge object represents to determine which template to pass in.
hmm.. sounding reasonably complicated but do-able. I might have a play later but unfortunetly have to work on another site at the moment
as to whether it will help serges issue. I'm not sure
... I've not looked at shadowbox.. But I think it will help.
Ben
Benjamin Albert Smith - Photography
Posts: 225
Actually.. what might be a good feature request, is that a theme developer could create a say "gEditUserForm.html.php" view that could be a template for the forge form. This could be implemented using the method I described above.. in the Forge toString method (or if it uses render else where) check the form id.. look for a view based on the form id... if it exists then load that to allow the dialog to be customised. If it doesn't exist then just use the default render method.
Dunno if it's worth adding that to the feature request list?
Ben
Benjamin Albert Smith - Photography
Posts: 2466
@nivekiam: yes, I am trying to do this at the moment.
Question would be - how much of the core would I keep in the theme and how would it affect version control
@Glooper: as you have noticed there are two dialogs: login and user info, both are partial html returned by the means of the AJAX request.
There are also "progress" messages which need to be handled, but I do not think it is a big issue.
yes, there is a little to affect customization without overriding the core or... as it was mentioned, copy associated html.php file into your theme and recreating it. This is part of my current experiment with the theme.
Posts: 16504
Serge D, I believe the stance right now is that it's up to the user (site administrator) to check if their theme(s) and non-core modules are compatible with the new version of Gallery. The upgrade instructions are going to be similar to:
* Disable all 3rd party modules and themes (set your theme to default, which will be named something else by the time RC1 rolls out, or something else that ships with G3)
* Upgrade G3
* Upgrade modules and themes (download and unpack new versions)
* Switch back to your favorite theme and activate modules when they are compatible with the new version of G3
I believe this is similar to what people running Drupal and WordPress have to do now. If your site runs on Drupal and it relies on some community module, you can't just go out and upgrade your site to the new version of Drupal until that module is known to work on that version of Drupal.
While I don't foresee major changes really breaking most themes (after the css refactoring has been complete that thumb posted about in another thread), if you've overridden a lot of core code in your theme that could make upgrading a little more work.
I don't see most security fixes if we happen to have to ship 3.0.1 breaking anything you'd be doing, however, you would probably need to check to see if any of the core files you are overriding are any of the affected files. However, on version jumps from 3.0 to 3.1 you'll most likely need to update the theme.
Right now, this is the way things are, you may need to override a bit to get what you want done. If it turns out that enough people want it and we can make changes to the core code to make some of this stuff easier that may happen. I'm just a support guy with a voice and not a dev, so I don't know the work that goes into it either or all the up stream stuff changes like this can make either.
I know with G2 some theme developers had to modify core files. The instructions in the early days were that those files had to be replaced in the core file system (one reason I never used those themes). Later, with G2.2, IIRC, the themes could override core files, from any module, at the theme level. You could even deal with versioning because G2 had this overly complicated check for everything system. It was a very confusing system that I doubt very many people took advantage of.
_______________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 2466
@nivekiam: I think we are off track here.
G3 is not compatible with G2 themes by design. And we are not talking about upgrading from G2 to G3 in the first place.
G3 is for sure a great improvement over G2 and I overall like the direction it is going.
While I do not mind to sync structure of the theme files it is inefficient to also sync any changes done to core modules.
Cascading file update module is a great feature of G3 and it does help a lot.
What I am advocating is separation of themes and core logic. Theme purpose to skin the core API not to mod it.
While there is understandable risk of running into situation when *some* core files need to be adjusted to accompany for the the theme requirements, theme related stuff should be abstracted from core modules logic or at least should be easy to override.
I have great experience working with WordPress from few years now and updating of the theme usually is not an issue. And with WP structure theming is usually simple because of the abstraction.
What I am trying to advocate here is that Generated elements need to be defined abstract enough to be skinned in the theme rather then imposed by the core: top menu style, button styles and visibility, even block structure should be not imposed by the core but defined by the theme instead.
Same time elements should be clearly defined by the core to be accessible for theming in CSS. Core structure should not imply that top menu is horizontal and have to use superfish (a little stretch here, but I hope you see where I go with this). On another hand, there is no reason to say that <UL> is gMenu but it is not gSiteMenu and use <DIV> just for that.
Similar applied to gViewMenu or gToolbar.
I applause the desire to simplify structure of the document advertised in original design document, at the same time we have areas which could benefit from simplifying some of the boxing structures.
As I said, I have no problem doing a little hacking of the core code (for example to enable BBCode support), but would like to be free enough to customize themes as I see fit. This applies to the elements, dialogs or id and classes used.
Posts: 16504
I was just throwing G2 data/history in there for reference.
I think you make very valid points, at least from a very technically savvy, non-coder point of view it sounds good
. I'm just not one of the guys writing code, so I have no idea what kind of changes it would take to implement. I also doubt they'd be changes at this point for this first release. I tossed the G2 reference stuff in there to show that G2 evolved over time and I'm sure G3 will too. Maybe it won't be perfect at 3.0, but it will be for 3.1 
(just kidding), but I'm sure changes for the better will be made. After those who are hesitant to try or adopt beta software start getting onto G3 after final release and we start getting more feedback from a larger audience, the voices in our heads will get louder 
Trust me, your feedback is very much appreciated and needed. It does not fall on deaf ears. Even the devs who don't post very much do read the posts in here and us support people help point stuff out to them too
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here