Hoping someone has experience in both community server 2008 and TS 5.0
What are the main differences when in comes to themeing?
The theme/layout system is quite different. Most of what used to exist in a theme (e.g. Fiji) was a set of files that you could customize. Now, those files are in the "generic" theme folder. Instead, you are to create your own "widgets" and add those to your theme.
To create widgets, you'll need to create a new class library and create classes that implement specific Telligent widget classes.
You can read more about the changes on Telligent.com
Widgets defined
Customization guide (free telligent.com login required to download)
Related
I want to build an web application(ASP.NET MVC 6) that can add modules/plugins without having to rewrite my source code.
Already read about MEF and Areas but are not helping much.
Someone who has overcome this problem that can help me?
Depends on which part of the web application you are targeting.
1.If it's in the request pipeline you would make a Middleware package.
2.It's it's in HTML you would make a TAG Helper package.
3.If it's an intrinsic functionality you would extend appropriate classes and throw them into a package. An example of this would be helpful extension methods or methods to add claims given a claims principal.
4.If you want to go even further you could create your own Visual Studio templates that you can use to pre-fill your options upon creation.
or "How to decouple UI from business logic in Delphi?"
Each target platform has its own set of native firemonkey controls (Windows=VCL, MacOS=TMS mCL, Android=D.P.F, iOS=TMS iCL and D.P.F). The new FireUI (multi-device form designer) is a great solution for styled components, but not for native components because it still requires the same component on the master pane to support all platforms. As you cannot mix them on the same form, it completely breaks the whole idea with Delphi.
A lot of developers would say that Delphi is the broken approach, see "Why FireMonkey is so fundamentally wrong in every aspect". However, the premise for this question is NOT to argue against Delphi, but to get the best results out of what it does offer.
The conclusion is then that for each form in your application you have to make a separate form for each target platform. This leads to these questions:
Challenge 1: How to include different form files in your project depending on your target platform?
Solution 1: include all of them, i.e. MainForm_IOS.pas, MainForm_Android.pas, MainForm_Win, MainForm_OSX.pas, and then use compiler directives inside the files, so only the content of one of the files is active. Disadvantage: a large application can have many forms (we have around 40), so we are talking about a large number of included files.
Solution 2: Do not include them in the project, but instead just place them in seperate folders. Then you can add the matching folder to the search path for each target platform. Disadvantage: They will not show up in the Project Manager, so it will slow down the workflow every time you need to find a file.
Solution 3: Create a project for each target platform. Disadvantage: Every time you add new units or change common project settings you have to (remember to) apply it to all projects.
Update: As suggested in the Malcom Groves video, placing all the business logic in a package will remove the disadvantage from Solution 3. So I consider solution 3 as the best approach.
Challenge 2: How to connect the different device forms to the (same) business logic?
Possible solution: Create a "Helper" class that contains all the code you would normally have in the form unit.
Update: This "Helper class" is actually what the MVVM calls a ViewModel. What I need seem to be a MVVM framework that can support the databinding. I have made another question about that.
Any input and suggestions about best practice are welcome.
For challenge 1:
You can conditionally link in your FireMonkey form resources depending on the compile target:
{$R *.Windows.fmx MSWINDOWS}
{$R *.Macintosh.fmx _MACOS}
etc.
This is excatly what the XE7 Multiview designer does, but I see nothing against using this mechanism to link whole form files conditionally in to your executable. Of course you might also want to ifdef the corresponding units in your project file.
For challenge 2: Just use some form of Model View Controler logic. So your platform dependant forms will talk to a platform independant controler.
I was wondering if page templates can be built instead of individual components in Teamsite 7? I've seen other cMS systems where it is just a page template that has lots of functionality built I and you can "switch" on and off elements that you want to display instead of having to drag components onto a page? Is this possible?
Old question, but since I just came across it:
Yes, TeamSite supports templates (.template) files which can be partial or full page templates. The default location is iwadmin/main/livesite/template.
I recommend downloading the developer guides from Autonomy's web site for detailed information.
Templates in teamsite/livesite is like a bag that can contain components. But in order for a functionality to be developed in teamsite/livesite we need to create components. certainly we can avoid dragging and dropping components in each page by creating templates and dropping components within it for once. Keep in mind templates are bound to layouts. for each type of layout we need to create a template. Please have a look at TS_7.3_SiteDeveloper_rev1, Chapter 5.
Yes, you can create templates instead of dragging components.
Since, TeamSite supports templates (.template) files which can be partial or full page templates and resides at location : iwadmin/main/livesite/template.
So, whenever you try to create a new page everytime the HTML code required for that page gets automatically added with the template and layouts you selected.
But, again this is not good since you can have any number of templates you need but this could create confusions at times when you try to create a new page since you will need to remember every template name and contents that you will need for a particular page so it's better to have small lists of templates and layouts since then we can say that there is reusability in our application/website which we are going to develop using Teamsite and Livesite.
Please vote the solution if its helpful.
Thanks!
In Community 4.0.a, I'm posting my custom activities in the repo following this: http://wiki.alfresco.com/wiki/3.0_Activities_Developer_Guide
I have defined my own activity type, with custom bundles and pagelink to display custom needs in the activity dashlet.
But I face an issue, I need to specialize the output based on the activity-type in a similar way of what is done already in activity-list.get.js in the specialize() function.
I can't hack the js cause I'm packaging things in my own amp for Share.
What is the best way to do it? Is there some kind of extension point or do I need to override completely the dashlet?
The old way (3.x) to change the behaviour of a webscript controller is to copy the code and overwrite the Javascript by placing it under web-extension: alfresco/web-extension/site-webscripts/org/alfresco/components/dashlets/activity-list.get.js. There you can modify the specialize() function or whatever you need to do.
All files you place in the alfresco/web-extension/site-webscripts folder will replace original files in the share.war WEB-INF/classes/alfresco/site-webscripts classpath. Best practice is to place your customizations in the tomcat/shared/classes/alfresco/web-extension folder so you don't need to modify the WAR file.
Alfresco 4.0 provides a new way to change the javascript controllers of a webscript. You can add additional Javascript code that will run after the original code. This is preferable because you don't need to change original code and you can upgrade more easily later. To use it you need to get familiar with the new Share extension modules concept. See David Draper's Blog for more info on that.
I really like the Ria Services approach, and I see Lightswitch as the next higher level of abstraction, but my scenario is this:
I need to be able to define a Lighswitch app without having to rely on the designer and tedious click-throughs. If I have access to the API that the designer uses, then I can automate application generation, I can parameterize it and apply custome logic for generating custom variations of the same application type, I can even wrap it within a DSL. As a programmer, I want to levarge Lightswitch for developing applications by meta-programming.
I'm a programmer. Whilest I can use the "Write Code" dropdown to insert code blocks into the Application, ApplicationDataService, EntityObject and ScreenObject classes, I would like the ability to define entites, screens, relationships and queries through code / markup / a DSL.
Obviously Lightswitch meta-programs this when I use the designer, but I would like to do it myself. What I would like to accomplish is to create a lightswitch app - without having to click through a tool or designer. In Lightswitch, the pieces are obviously there (the designer leverages them), but they are not exposed as a public API. being a plugin for visual studio, perhaps there is a VSIX API extension I can leverage for automating Lightswitch? Show me some code.
The LS team have not yet released any official API information. As you may know however, all of various data/query/screen definitions exist in the ApplicationDefinition.lsml file, located in the LS project's "Data" folder.
I would hope that API information will be made available once the RTM has been released.
Yann